Microprocessors and Microsystems 32 (2008) 270278

Contents lists available at ScienceDirect

Microprocessors and Microsystems

journal homepage: www.elsevier.com/locate/micpro

Simulated fault injections and their acceleration in SystemC

Silvio Misera *, Heinrich Theodor Vierhaus, Andr Sieber
Brandenburg University of Technology Cottbus, Computer Engineering Department, 03046 Cottbus, Germany

a r t i c l e

i n f o

a b s t r a c t
SystemC has found a large acceptance for the description of electronic systems. An essential advantage of a SystemC description is the possibility of a built-in compiled-code simulation. Beyond the functional simulation for validation of a hardware design, there are additional requirements for an advanced simulation of faults in order to analyze the system behavior under fault conditions. The article introduces known and novel methods of SystemC-based simulations with fault injections and provides simulation results. Some strategies are shown to accelerate the SystemC simulation by parallel computing. Furthermore, we present gate level and switch level models for an effective simulation in SystemC. 2008 Elsevier B.V. All rights reserved.

Available online 4 May 2008 Keywords: SystemC Simulated fault injection Switch level Accelarated simulation

1. Introduction Electronic circuits need sophisticated test procedures that run efciently and provide high fault coverage. The simulation of faults has different reasons. First, there is the fault simulation for the validation of test patterns for fabrication faults. Second, there is the simulated fault injection that investigates the occurrences of faults during the operation of the system. It is of an increasing importance to examine the behavior of SoCs (Systems on a Chip) under fault and error conditions, since transient fault conditions become more likely for nano structures. Such errors can be single event upsets (SEUs), caused by electromagnetic radiation or particle radiation. Fast and efcient gate level fault simulators have been available since the early nineties [2], mostly in the automatic test pattern generation (ATPG) software. These tools are unsuitable for the simulation of heterogeneous systems such as SoCs due to their limited applicability to real designs. The simulation and especially the fault simulation is meeting new challenges because of the interaction of different groups of logic, memory, buses and more. Regarding to different components and the spectrum of fault types, it is useful to develop and to analyze different kinds of fault injection techniques with references to their effectiveness. The usage of a high level language is integrated in the rst phases of the system design procedure, especially the use of C/ C++ language. The need considers hardware characteristics early in the design phase. It grows with the increasing renement of a design, e.g. for concurrency, hierarchy or logic data types.

In order to comply with such requirements, a few years ago the open SystemC [3,21] was developed as a C++ class library. Since then it has been possible for the C++ programmer to describe systems in one environment with no translation into a Hardware Description Language (HDL) as necessary before. The most well known hardware description languages are Verilog and VHDL. Aside from the additional characteristics which distinguish an HDL, a SystemC description can still use the full language scope of C++. Instructions and characteristics are possible in this way, which permit also abstract behavioral models, as they are necessary for the early phases of the design. A seamless mixed simulation of structural models and behavioral models is not a problem. With effectively specied designs, SystemC reduces the simulation time or it facilitates the validation of the rened model against the original behavioral model, optionally under fault conditions [1]. The distribution of this article is as follows. In Section 2 we explain shortly fault injection techniques of VHDL descriptions and the few approaches which were presented in SystemC so far. After this we present our realized implementations of fault injections by the usage of SystemC. Here, the suggested techniques are optimized for simulations at register-transfer, gate and switch level. We present several acceleration approaches for the simulation by different kinds of computation in the third section. In Section 4, some interesting components are shown which underline the effective use of SystemC in low level design phases of a circuit.

2. Methods of fault injection The simulated fault injection (SFI) in HDL models is well investigated [7,11,13,15,17]. It is a feasible way to validate systems with fault tolerance. Earlier approaches were limited to VHDL and Verilog descriptions mostly.

* Corresponding author. E-mail addresses: sm@kjellberg.de (S. Misera), htv@informatik.tu-cottbus.de (H.T. Vierhaus), asieber@informatik.tu-cottbus.de (A. Sieber). 0141-9331/$ - see front matter 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.micpro.2008.03.013

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278

271

Three methods have been established, regarding to the fault injection in hardware descriptions:  Saboteur an additional fault injection module is inserted into the signal path between two or more components. The fault injection is activated by a control input.  Mutant a component is replaced by another with extensions. This component contains the characteristics to effect one or more cases of a fault behavior.  Simulator command the value of a signal or a variable is manipulated. Such a simulation for stuck-at faults can be automated well by using macros and/or scripts [4,9]. The use of these fault injection techniques in SystemC is still very scarce. Earlier approaches were often limited to one specic design level, done by a simple fault injection or they used only one fault model. An approach is presented in [6] which works with a determined set of HDL primitives and a fault injection technique, similar to the saboteur method. In [5,20,23] are fault injections done in behavioral models. The way how code modications are done in [20,8] is a kind of a mutation method restricted to few instructions. In [5] the presented method is restricted to nite state machines and in [23] the saboteur method is preferred. All presented approaches with fault injections in SystemC models are restricted regarding to design levels of fault models. There is still no exploration and comparison of different fault injection techniques for SystemC such as done in [7] for VHDL. Our article presents several fault injection techniques in SystemC and presents rst benchmark results, too. 2.1. Saboteurs Inserting saboteurs is a popular method because it is relatively simple to implement. However, the variety of the fault modeling is restricted and it is often used for simple models only. Fig. 1 shows the modication of an original signal path by an additional saboteur module. The fault is activated depending on the value of the control pin. The saboteur insertions are differentiated in three sub-methods, the serial structure, the complex serial structure and the parallel structure [17]. The serial method is simple and often used to inject stuck-at faults. It is also an easy way to insert delay faults in interconnects when using SystemC. Fig. 2 shows the fault injection code of a SystemC example for stuck-at faults. With the use of the complex serial method, cross talk errors can be simulated, too. The parallel method is suitable to excite disturbances on buses. 2.2. Mutants Mutants are differentiated in two categories. The rst method replaces a correctly working component by an incorrectly working component. An AND gate is replaced by a NAND gate, for example. It could be implemented by mutations in the SystemC code, exactly the component instantiation must be modied. However, the circuit model can be changed only before compilation. A dynamic replacement is not possible during the simulation in SystemC yet. For a sequential fault injection, as it is used in practice, a new compilation and linking for each injection becomes necessary. But every recompilation needs a lot of time. Therefore this method has no practical importance in SystemC designs today. In the second category of mutants, the correct components are replaced by modied components. These modications are usually extensions for the fault modeling. By an additional control input pin the fault condition is activated or deactivated during the simulation. It is demonstrated in Fig. 3. This method is very customizable and allows the implementation of arbitrary models and also of new fault models. Additionally, it is well applicable to SystemC, and it is at least as effective as a comparable VHDL equivalent type. Fig. 4 shows a mutant in SystemC for stuck-at faults. 2.2.1. Parameterized mutants Components using generic parameters in VHDL are often used. The advantage of this is one exible module which can be used for different cases. The parameterizing is possible for the design structure, the values or the attributes. Parameterized modules are in SystemC usable, too. The Parameters can be resolved at different times. Interesting solutions are the resolving at compile time and the resolving at elaboration time. The resolving at compile time happens by the usage of templates in SystemC. This coding style is very exible and an advantage is e.g., in comparison to VHDL where it is impossible, that the type of a signal can be parameterized. Fig. 5 shows a fragment of code for a templatemutant. Another method to parameterizing a module is the use of C++ constructor arguments. The values are resolved prior the start of simulation when the design hierarchy is constructed. This method is less exible than the way with the use of templates. But it has

Fig. 2. Saboteur for stuck-at faults.

Module A Control

Module B

Module A

Saboteur

Module B

Module A

Module B Control

1
Fault

0
Control active Control inactive

Module A

Mutant Module B

Fig. 1. Modication scheme of a saboteur.

Fig. 3. Modication scheme of a mutant.

272

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278

Fig. 4. NAND2-mutant in SystemC.

Fig. 6. Constructor-argument-mutant.

2.3. Simulation commands Additional commands exist in several HDL simulators which allow the manipulation of signals and variables. The using of this method depends on the implemented features of a conventional HDL simulator. These simulator commands, sometimes denoted as built-in commands, have the advantage that they do not need modications of the circuit description. There are no specic equivalent structures implemented in SystemC up to now. But we developed extensions to SystemC that allow for related commands in SystemC, comparable to the known commands in HDL simulators. The usage of these commands is just as easy as in HDL simulators, but the fashion of their implementation differs. Therefore we denote our technique as simulation commands. This fault injection makes usually a difference between variable manipulation and signal manipulation. For a simple variable manipulation, the following example statement in the test bench is sufcient: Submod1.Var1=1. This command works temporarily, that means any succeeding action in the model can dismiss the fault injection. It is good for transient fault injections, permanent fault injections are impossible to cover with such a single command. This behavior is related to fault injections in signals. A permanent fault injection or an injection for a determined simulation time is quite difcult. Therefore we made basic extensions to the SystemC library. 2.3.1. Simulation commands for signals The signal manipulation in accordance with [17] is done that the simulation is stopped after a certain simulation time. Then the signal is removed from the driven input, and a new signal value is forced. After this, a simulation takes place for a certain time with this forced signal strength. If the fault injection is done, the signal is connected with its original input again. This procedure is a problem in SystemC. It is possible to leave ports unconnected in the new SystemC-release [22], but nothing is known about the possibility of dynamic re-wiring.

Fig. 5. Template-mutant in SystemC.

the advantage that original program code is not necessary. IP (intellectual property) vendors can ship their components and keep in secret their know-how. Fig. 6 shows a fragment of code for a constructor-argument-mutant. The use of parameterizing leads to modied functions and therefore to an overhead in the program code. In Figs. 5 and 6 the operations are done in loops. Here, it is interesting to examine if these modules are less efcient than simple modules. Table 1 shows different simulation results for three designs. The circuit c17 is a small ISCAS benchmark circuit. The circuit decod is combinational decoder circuit and the circuit fsm6 is nite state machine with six ip ops. Surprisingly, it can be seen that the parameterized solutions are a little bit faster than the non-parameterized way in most cases. The constructor arguments deliver the best results here. The C++ compiler is able to build efcient programs from the given parameterized modules.

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278 Table 1 Simulation results for parameterized examples Design Speed-up Normal module With output decod fsm6 c17 1.0 1.0 1.0 No output 1.0 1.0 1.0 Template-module With output 0.99 1.001 1.00 No output 1.01 1.057 0.973 Constructor-module With output 1.01 1.036 1.01

273

No output 1.01 1.117 1.0

We solve the problem in our approach in two steps. At rst we examine the requirements of data types and manipulation methods. After this we examine the fault injection and interaction during the simulation. The rst point is solved by overwriting some classes in the SystemC library. The important changes for the fault injection technique in signals are done as follows.  The data type sc_logic is extended by additional values (B, A, R); sc_fi_logic e {0, 1, Z, X, B, A, R}.  These values are assigned to new signal strengths, the class sc_signal_resolved is overwritten. The value A (Above) means a strong 1, the value B (Below) means strong 0 and the value R (Release) is a new special type.  The operator methods of sc_logic were extended for the new values (&, |, ^, , etc.).  In addition some conversion tables are extended for an useful type casting.  Other methods, e.g. for signal tracing, are overwritten. Preparations are made for stuck-at fault injections by the new signal values now. An injection of A leads to a stuck-at-1 fault, signal B leads to a stuck-at-0 fault and R releases the signal again. Table 2 shows the resolution of the signal strengths. An accurate checkup shows that R is sophisticated. The signal R has an higher priority than A or B, but is weaker than Z. This tricky way allows a permanent fault injection and also its removal after a specied time. The simplest kind of the fault injection looks like, regarding to the SystemC user guide 2.0.1 [3], that the device under test (DUT) is supplied by an input module with the input pattern in a test bench. The signals must be connected with ports for the fault injection. However, this method inates the circuit model signicantly. We used in our solution the possibility of C++ to get access to signals without the implementation of additional channels and ports. Instead of the usage of the generic sc_start(..) command in the test bench, we use the instructions sc_initialize() and sc_cycle() to control the fault injections during the simulation. For example to inject a stuck-at-1 fault there is the following instruction sufcient in the top level: Mod1.Submod1.Sig1.write(sc_logic_A). 2.3.2. Simulation commands for variables We mentioned above (Section 2.3) that a simple manipulation of a variable is temporary. The fault injection is not controllable
Table 2 Resolve table of signal strength 0 0 1 Z X B A R 0 X 0 X B A 0 1 X 1 1 X B A 1 Z 0 1 Z X B A Z X X X X X B A X B B B B B B X R A A A A A X A R R 0 1 Z X R R R

and therefore the duration is not certain. A manipulation of the proprietary data types is not allowed in C++. A modication of the SystemC library, as we used it for signals, is not practical here. The problem was solved by the creation of new data types. The new data types, inherited from C++ types, obtained an additional access-ag which helps to control the injection. Further, operators and methods for the use of the access-ag were implemented. A code fragment of the new class is shown in Fig. 7. The new data type works in the following manner. The normal operators (e.g. *, +, =) allow the functionality as it is known from C++ types. A lock-method at the access-ag leads to a frozen variable and an unlock-method releases the variable. If there is the desire to inject a fault, the fault value must be written and then the lock-method have to be called. After a certain duration, the fault injection can be removed. An usable fault injection is possible by this way. 2.4. Comparison of fault injection techniques The third method (simulation commands) is suitable for stuckat faults mainly. However, it did not need any changes of the circuit. The test bench preparation with the simulation commands is the easiest one. A modication of the circuit description is necessary when the rst two methods are used. In our experiments, we wrote perl scripts for the manipulation of the SystemC descriptions. The usage of the scripts automated the preparation for the simulation well. The preparation time is less in comparison to the time of compilation and simulation. In practice the additional ports for fault injection in saboteurs and mutants inate the circuit model. Table 3 shows some simulation results done with the presented fault injection techniques applied to three benchmark circuits. Stuck-at faults were injected. The model K1 is the smallest one with few logic gates, and the model K2 is the biggest gate level

Fig. 7. Class for fault injection in variables.

274 Table 3 Simulation results with different fault injections Circuit

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278

3.1. Bit-parallel simulation 3.1.1. Pattern parallel simulation The easiest way to a parallel simulation is to bundle items of bivalent logic of independent data to a word. While a simple simulation uses only one single bit in a word, a theoretical acceleration of the simulation exists with the parallel use of the bit number of a machine word. On a commonly used PC with a standard ANSI C++ compiler, there would be a speed-up with a factor of 32. But operations are only easy to implement for parallel execution, for which a corresponding machine command exists. Fig. 8 claries this. All bits become in use here and are calculated in one step by an AND operation instead of only one bit. Unfortunately, there are too rarely independent input vectors in the most simulation cases. The circuit simulation is here usually restricted to combinational parts. In sequential circuits, the individual circuit conditions are depending on each other. The pattern parallel method delivers wrong results here. There are admittedly two approaches published for the pattern parallel calculation of sequential circuits [25,26]. However the administrative effort for the realization of these algorithms in an object oriented and heterogeneous environment, such as in SystemC, should be expensive in calculation time. But sequential circuits can be handled by a pattern parallel approach in case of the existence of independent sequences. For a processor description, these can be several programs, for example. Then a simultaneous computation is possible. A temporal scheduling of programs with equal sizes of input sequences leads to the highest acceleration in simulation time (balanced computation). 3.1.2. Fault parallel simulation Another approach is the parallel computation of several fault injections for one input pattern in one step. The fault injections have an independent behavior from each other. Additional expenditures are necessary in the parallel injection of faults in the model. Fig. 9 shows an effective realization of the fault injection with a saboteur by the usage of logical operations. A stuck-at-0 fault is achieved by an AND operation with the complement of the fault-selection-word and a stuck-at-1 fault is realized by an OR operation. A 1 into the desired bit place of the fault-selection-word injects the fault. Beyond the way of logical operations, further procedures are possible for the fault injection. For example, this can be achieved with a switch-case command like in Fig. 9. Since the number of applicable operations rises linearly with the degree of parallel execution, this action is not recommended here because of the rising simulation time. Another popular realization is the table-controlled method, because it is fast in simulation time. A corresponding table entry is delivered by the transfer of parameters from a constant array. However, the storage demand grows exponential with the increasing bit width, but a high bit width is often desired in parallelizing and also for the use of all possibilities. A typical 32-bit-machineword has already 232 possibilities! Hence this method is not recommended here.

Time (normalized) K1 MSAB 1.00 1.01 1.36 1.32 1.40 3.14 K2 1.00 1.23 1.96 1.81 1.84 5.21

Simulation commands Mutants with sim. commands Mutants Saboteurs with sim. commands Saboteurs FIT (VHDL fault injection tool)

1.00 1.01 1.05 1.28 1.30 3.71

circuit with several hundred components. These models have no practical signication. The method of the simulation commands is the fastest one. The models mutants/saboteurs with sim. commands are a blend. The fault is here not enabled by additional ports and channels. The fault control input is here an additional signal within the component. This control signal is activated like in simulation commands (Section 2.3). One command is sufcient like: K1.DUT.AND2.SA.write(1); in the top level of the test bench. The simulation of a circuit (mutants with sim. commands) modied with mutants is just a little bit slower. But this model combines the speed of simulation commands and the versatility of the mutant method. The traditional methods of saboteurs and mutants with additional ports and wires are signicant slower. It could be seen that the replacement of the control ports for the fault enabling by simulation commands leads to faster simulation times. The FIT model is presented for comparison. This is a circuit simulation with a VHDL Fault Injection Tool [16]. Here it was shown that it is useful to analyze different types of fault injections in SystemC simulations in detail and to use novel approaches like simulation commands. 3. Acceleration of the simulation It was shown in Section 2 that a simulation based fault injection in SystemC is practical. Another requirement is the fault simulation for the evaluation of the fault coverage of input patterns. This application is often used in the ATPG process. With growing circuit sizes, the simulation and especially the fault simulation gets the challenge to be executable in a reasonable time. But fast gate level simulators are restricted in the modeling of their components, and todays circuits consist of several heterogeneous components like gates, memories, PLLs. Normally, a HDL could help here, but it fails in terms of simulation time [10]. An alternative is the simulation of faults in details for a part of the model, the remaining parts are simulated by fast behavioral models [8]. It was also presented in [8] that simulation speed in SystemC is much higher than an equivalent simulation in VHDL. Our experiences conrm this. Therefore we do not only work with fault injections for the validation of models in eld. We think also about a fault simulation in SystemC, e.g. for the creation of a fault dictionary. But the main problem is still the long simulation time. A long existing technique to accelerate a simulation is the parallel computation. The parallel computation can be subdivided into several levels. We present the parallel execution by data computed with one processor here. Other parallel approaches split the program execution [24] or use the distributed computation in a PC cluster [16]. There are no experiments in simulation of faults in SystemC by now. This section is organized as follows. At rst we present our approaches of the bit-parallel simulation within a machine word. After this we show solutions to calculate multiple-valued data. In the last subsection we present two approaches of parallel data computation at a higher level.

A
{a0,a1,...,ax}

B
{b0,b1,...,bx} {

C
{c0,c1,...,cx}

A&B=C
{a0&b0=c0,a1&b1=c1,...,ax&bx=cx}
Fig. 8. Bit-parallel AND.

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278 Table 5 4-Valued simulation Design sc_logic (1) Speed-up c17 fsm6 Decod MSAB 1 1 1 1 sc_lv Speed-up 2.83 7.84 6.28 2.27

275

sc_sd<32> Speed-up 2.95 9.08 6.95 3.81

Fig. 9. Fast parallel saboteur.

Some fault simulators work only effectively, because they use the single propagation model [2]. For the evaluation of test patterns for the production test, this may be sufcient. For the simulation within the design phase this is not usable, because there is an occurrence of several simultaneous faults sometimes. The introduced SystemC approach above allows multiple fault injections for one simulation step. Table 4 shows simulation results for combinational benchmark circuits. The algorithm C1 is not using parallelism, C32i uses 32 parallel input patterns in one step, and C32f computes with 32 faults simultaneously. 3.2. Four-valued logic simulation The simulation with bivalent logic may be sufcient for a functional logic simulation or for a simple simulation with stuck-at faults. For an usable fault simulator, a 3- or 4-valued logic type is absolutely necessary. A fault simulator, which is used in the automatic test pattern generation (ATPG), needs often unknown X values to compress test patterns. On the other hand, the computation with unknown values is also necessary for the examination of fault tolerance of a system because signals can collide here. SystemC offers the four-valued types sc_logic as well as the class sc_signal_resolved. There are the vector types sc_lv<> as well as sc_rv<> for buses. These types are also good for parallelism. For the parallel implementation, the signals, variables and ports must be changed only into vectors. A declaration of a signal swaps, for instance, from sc_in<sc_logic>IN1 to sc_in<sc_lv<8> >IN1. These modications can be automated well, e.g. by the use of (perl-) scripts. The basic methods must not be changed, since the logical operations of sc_logic and sc_rv<> are similar. Another procedure of the parallel calculation with four-valued logic is the fashion which is used in several fault simulators [12]. Here, the coding of a value takes place in one bit in two machine words (V0, V1), respectively. The coding of the values is executed as follows: 0 as (1, 0), 1 as (0, 1), X as (0, 0) und Z as (1, 1). This kind of coding is optimal to perform the actual operations with few logical operations. For an invert function, there are only the two operations V0 = A1 and V1 = A0 used. A0 and A1 are the input vectors. This approach is well done in SystemC. First simulation results showed that the advantage is better in comparison with the procedure of the usage of the SystemC data type sc_lv<> (Table 5: sc_sd<32>). Furthermore, the coding of the values of the nally introduced variation is not SystemC-compatible. If there are other SystemC functions in the simulation necessary like sc_trace(), an additional cast method must be implemented. Here the sc_lv-usage is easier to implement.
Table 4 2-Valued simulation Design C1 Time (s) K01 MSAB 58.65 63.27 Speed-up 1 1 C32i Time (s) 2.5 2.57 Speed-up 23.5 24.6 C32f Time (s) 2.7 2.43 Speed-up 21.6 26.0

Table 5 shows some comparative results of the four-valued simulation. 3.3. Parallelizing at higher levels The presented methods of parallelism before are quite effective. However, they are restricted at logical operations of a processor like AND, OR, XOR. Therefore these methods work only at the gate level. Arithmetic operations, as they are used at the register-transfer-level, do not nd place in one or two bits. At least one machine word is usually required for the representation of a data value. However, such a word allows also parallelism again. 3.3.1. Array-parallel simulation A parallel organization of machine words is possible within an array. The processes and methods get multiple parameter values. For instance, the expression sc_signal<int> MyDat is swapped into sc_signal<int> MyDat [8]. There are 8 signals of the integer type in place of a simple integer signal. An expansion in the sensitive list to all these 8 signals is now necessary in order to activate the processes. However, a for-loop is sufcient, e.g. for (int i=0; i<8; i++) sensitive<<in1[i]<<in2[i];. Similarly, it looks like with the wiring of the modules, an example could be: for(int i=0; i<8; i++) {M1.a1 [i] (SIG_IN1 [i]); ...}. After this, the implemented functions must only be executed in loops to ll the arrays. The aim of this approach is that multiple parameter values take place in one process call and the number of the process calls is minimized by this way. Maybe the adaptations appear tedious, but it is a feasible way. It is also possible to automate this adaptation, and the reuse of models minimizes the effort additionally. Some simulation results for two SystemC models are presented in Table 6. It is shown that this parallelism approach leads to a measurable acceleration, but the speed-up apparently stagnates from a certain degree. The speed-up is for models with a high calculation effort (no output) much better. The not existing data outputs lead to a better performance. The add8 is a very simple register-transfer level model, and alup is a more extensive model which executes several operations concurrently. 3.3.2. Parallel-dened data type simulation Instead of the approach to multiply a signal type described in Section 3.3.1., it is also possible to create a new data type (PDDT)
Table 6 Simulations with array of signals Used numbers of integers Speed-up add8 Output 1 2 8 16 32 64 1 1.4 1.22 1.3 1.31 1.33 No output 1 1.75 3.0 5.6 7.48 8.1 alup Output 1 1.21 1.28 1.27 1.24 1.25 No output 1 1.41 2.09 2.14 2.27 2.32

276 Table 7 Simulations with high level types Used numbers of integers Speed-up add8 Output Simple serial 8-fold array 8-fold PDDT 1 1.96 2.22

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278

4.1. Logic type extensions in SystemC The data type sc_logic was extended for a more realistic behavior of SystemC descriptions. The steps, which were made here, are related to the changes described in Section 2.3. Therefore it is shown shortly. The logic type is expanded to the nine-valued logic type. We implemented the IEEE 1164 logic denition [19]. The additional values are:      L: weak 0, H: weak 1, U: not initialized, W: weak unknown, D: dont care.

alup No output 1 3.01 5.89 Output 1 1.92 2.14 No output 1 2.15 5.93

which consists of an integer array. A new class has to be created for this purpose. Then some base operators and all used operators must be overloaded in this class. The rst creation of such a class costs programming expenditure, but later on, it can be reused as often as needed. This method has an advantage, because there are less modications in the SystemC model necessary. Only the replacement of the data type is necessary, e.g. <int> to <myInt>. Which approach is recommended here? It depends on the case of application. In matters of implementation time, the parallel-dened data type approach (PDDT) dominates here. But if costly mathematical functions with complex operations occur in the model, and behavioral models with complex algorithms are quite usual, then the approach with the arrays of signals is to be preferred because of the programming effort. Table 7 shows comparative simulation results for two circuits. Additionally, there are results with high data output (output) and results with high calculation effort given (no output). It can be seen that the implementations with parallel-dened data type deliver the best performance. As the rst introduced approaches use the parallelism in the machine word (3.1, 3.2), the nally introduced approaches (3.3) are abstract and work quasi-parallel by the parallel data transfer within the process call. It is possible to get more speed-up with an incorporation of the approaches of 3.1/3.2 and that of 3.3.

The signal strengths were implemented in conformance to the IEEE 1164 standard. The operators, several conversion tables and methods were overloaded additionally. The result was a full achievement of the IEEE 1164 logic. 4.2. Switches in SystemC Switches are represented in VLSI designs as transistors. Two kinds of transistors are sufcient here. The pmos transistor switches on by a low level voltage on its gate pin. But the nmos transistor switches on by a high level voltage on its gate pin. Fig. 10 shows parts of the implementation of the nmos transistor. Some of the new logic values are in use there. The table is addressed by two input pins. The correct type casting and table selection is shown in the method nmos::doit(). The functionality is done by the table nmosTab. The realization of the pmos transistors is related, only columns of 0 and 1 are swapped. 4.3. Stuck-on fault model Fault models allow analyses more in detail at the switch level than at higher design levels. One switch level fault model is stuck-on. If there is a stuck-on fault, then a transistor is always conducting. Fig. 11 shows the modied model for the nmos transistor from Fig. 10. The fault is activated depending on the value of the control pin . The modied functionality is inherent in the table nmosTabFi. Here, the fault injection leads the input value to the output without notice of the gate pin (ctrl). 4.4. Transmission gate at the switch level We describe the usage of the transistor switches to assembly components in this section. The transmission gate is used here as

4. SystemC models with switch level behavior Several techniques of fault injection and different methods of accelerated simulations were shown in the sections above. The following text describes the implementation of a component at several levels of abstraction. Typical designs in SystemC are functional or RTL models. The usage of gate level models in SystemC is described in [14] well, and the modeling at the analogous circuit level takes place in SystemC-AMS [18]. But there is nothing known about SystemC models at the switch level. The seamless design ow, which was an aim by the introduction of SystemC, seems impossible. It seems that only Verilog-HDL contains the features to model here. But the modeling at the switch level is interesting for the simulation of faults, respectively. Here, the low abstraction of designs leads to precise models. The behavior of a switch level component in conjunction with a fault injection is more realistic. There was also presented that simulations of SystemC models are quite faster than simulations of other HDL descriptions [8]. Own experiments validated this. That is another cause for a desired usage of SystemC here. At rst, we describe our extensions made in the SystemC library for an useful switch level behavior. After this, the constructions of the switches are presented. A typical fault model is also presented for the switch level. Additionally, there is shown the assembly of these switches to a component and a description of this component with a higher abstraction is presented for comparison. Simulation results complete the section.

Fig. 10. Fast nmos switch.

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278

277

Fig. 13. Transmission gate consists if nmos- and pmos switch.

Fig. 11. Fast nmos switch with stuck-on fault.

an example, but nearly all other gates can be composed of switches. A transmission gate (t-gate) is a compact switch in CMOS technology. It originates from a combination of an n-channel and of a p-channel transistor. Fig. 12 shows the structure and the scheme of such a transmission gate. The n-channel transistor of the t-gate is controlled by the signal C and the p-channel transistor by the inverted signal /C. A high level at C leads to a closed switch and a low level implies an opened switch. In addition, a t-gate works bidirectional. For example, a signal can be switched from left (L) to the right (R) and reverse. But at the gate level in SystemC or in VHDL, it works in one direction only. That is not sufcient to simulate buses or multiplexers in detail. The essential SystemC code is presented in Fig. 13. The nmos- and the pmos transistor are here instantiated in a hierarchical design. The control ports are input ports and the data ports are inputand output-ports. This way allows a bidirectional function which is essential for the switch level modeling. 4.5. Transmission gate at the gate level A t-gate is implemented only as an unidirectional switch in many (VHDL) models (see Fig. 12b). First, some simulators have problems with the bidirectional modeling. Second, this simple description could be sufcient for a functional simulation. Fig. 14 shows the essential program code which is more compact than the switch level design. 4.6. T-gate simulations and conclusions Table 8 shows the simulation results for six benchmark designs which consist of transmission gates mainly. The fault injection was done by saboteurs here.

Fig. 14. Transmission gate at the gate level (unidirectional).

Table 8 Simulation times of TG circuits Design Simulation time (normalized) Gate level TGB1 TGB2 MUX16 K1 MSAB K2 1 1 1 1 1 1 Switch level 1.07 1.54 1.05 1.82 4.16 7.51

The effort of simulation time is interesting which is shown in the column switch level. It can be seen that the simulation time arises by a growing design size and different description levels sometimes because TGB1 is smaller than TGB2. But it is not dramatically. The design K2 is the greatest circuit. The loss in speed is the highest here. For a fast simulation the gate level description is to prefer, but the switch level model deals with more precise fault models or rather fault injection nodes. Additionally, the bidirectional data ow delivers a realistic behavior. At last, a switch level model helps the designer to validate a (novel) fault model for a high level of abstraction regarding to the realistic behavior. 5. Conclusion

a
L

/C R C

b
L R

Fig. 12. Transmission gate.

It was shown that the fault injection methods, like they are used in hardware descriptions in VHDL already in the past, can be realized also in SystemC well. It was shown that, beside the popular fault injection techniques of saboteurs and the temporarily data manipulation in SystemC models, the new presented approaches of mutants and simulation commands have advantages. Parameterized models, which are exible in their usage, work efciently too.

278

S. Misera et al. / Microprocessors and Microsystems 32 (2008) 270278 [10] B. Parrotta, M. Rebaudengo, M. Sonza Reorda, M. Violante, New Techniques for Accelerating Fault Injection in VHDL Descriptions, July 2000, pp. 61. [11] Seward, Lala, Fault injection for verifying testability at the VHDL level, Proceedings of the ITC IEEE, 2003. [12] Thomas M. Neirmann, Wu-Tung Cheng, Janak H. Patel, PROOFS: a fast, memory-efcient sequential circuit fault simulator, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 11 (2) (1992). [13] Benso, Prinetto, Fault Injection Techniques and Tools for Embedded Systems Reliability Evaluation, Kluwer Academic Publishers, 2003. [14] J. Bhasker, A SystemC Primer, Star Galaxy Publishing, Allentown, 2002. [15] M. Rimn, J. Ohlsson, J. Karlsson, et al., Design Guidelines of a VHDL-based Simulation Tool for the Validation of Fault Tolerance, 1997. [16] Misera, Vierhaus, FIT A Parallel Hierarchical Fault Simulation Environment, Parelec, Dresden, 2004, pp. 289294. [17] E. Jenn, J. Arlat, M. Rimen. J. Ohlsson, J. Karlsson, Fault injection into VHDL models: the MEFISTO tool, in: Proceedings of the 24th International Symposium Fault-Tolerant Computimg, IEEE, 1994, pp. 6675. [18] SystemC-AMS study group: SystemC-AMS, <www.systemc-ams.org>, February 26, 2007. [19] IEEE Package 1164, <http://ieeexplore.ieee.org/xpl/standards.jsp>, January 29, 2007. [20] Alessandro Fin, Franco Fummi, Graziano Pravadelli, AMLETO:a multi-language environment for functional test generation, in: Proceedings of the International Test Conference, 2001, pp. 821. [21] Black, Donovan, SystemC: From The Ground Up, Kluwer Academic Publishers, Boston, 2004. [22] IEEE Standard SystemC Language Reference Manual, <http:// standards.ieee.org/getieee/1666/>, October 10, 2006. [23] K. Rothbart, U. Neffe, Ch. Steger, R. Weiss, E. Rieger, A. Muehlberger, High level fault injection for attack simulation in smart cards, Found in: 13th Asian Test Symposium (ATS04), 2004. [24] OpenMP, <www.openmp.org>, January 10, 2007. [25] Kung, Lin, Parallel sequence fault simulation for synchronous sequential circuits, Journal of Electronic Testing (1996) 267277. [26] Nikolaus Goders, Reinard Kaibel, PARIS: a parallel pattern fault simulator for synchronous sequential circuits, in: Proceedings of the International Conference on Computer-Aided Design, 1991, pp. 542545.

Experiments have shown that different kinds of parallel computing speed-up the simulation. In the last section it was shown that switch level models are possible in SystemC. It was achieved with extensions in the SystemC library. This approach helps to close the gap between the gate level and the circuit level. The novel seamless ow is very interesting for examinations of fault injection experiments. SystemC is not among the fastest simulators, e.g. at the gate level. But SystemC allows multi-level simulations. Therefore parts of the design with fault injections can be modeled precisely at the switch or gate level, and the other parts can be computed more abstractly. This way leads to an acceptable simulation speed. References
[1] Baldez et al., LINXS: Using SystemC to Enable HW/SW Co-Simulation in the Real World, ESCUG, September 2005. [2] H.K. Lee, D.S. Ha, HOPE: an efcient parallel fault simulator for synchronous sequential circuits, in: Proceedings of the ACM-IEEE Design Automation Conference (DAC), 1992, pp. 336340. [3] SystemC: <www.systemc.org>, November 10, 2006. [4] Modelsim Designer: <www.model.com>, October 1, 2006. [5] F. Bruschi, F. Ferrandi, D. Sciuto, A framework for functional verication of systemc models, International Journal of Parallel Programming 33 (6) (2005). [6] F. Bruschi, M. Chiamenti, F. Ferrandi, D. Sciuto, Error Simulation Based on the SystemC Design Description Language, Automation and Test in Europe Conference and Exhibition (DATE02), 2002, pp. 1135. [7] J. Gracia, J.C. Baraza, D. Gil, P.J. Gil: Comparison and Application of Different VHDL-Based Fault Injection Techniques, IEEE International Symposium on Defect and Fault Tolerance in VLSI Systems (DFT01), October 2001, pp. 0233. [8] W. Mller, W. Rosenstiel, J. Ruf, (Hrsg.): SystemC - Methodologies and Applications, Kluwer Academic Publishers, 2003. pp. 127156. [9] Aldec Inc., Active-HDL und Riveria, <www.aldec.com>, November 1, 2005.