NOT NOT AND

This research describes about the testing of virtual reconfigurable circuit (VRC) designed and implemented for a fault tolerant system which averages the (three) sensor inputs. The circuits that are to be tested are those which are successfully evolved in this system under different situations such as (i) all the three sensors are faultless (ii) one of the input sensor fails as open (iii) sensors fails as short circuit. The objective of this research is to test the desired optimal circuits evolved by decoding the configuration bit streams. The logic simulation tool used to perform fault simulation is AUSIM (Auburn University Simulator).


INTRODUCTION
Ensuring the reliability of Electronic Circuits has always been a challenge. As the complexity of systems increases the inclusion of reliability measures becomes progressively more complex and often a necessity for VLSI circuits where a single error could potentially render an entire system useless.
The Evolvable Fault Tolerant system [1] is designed (1) to provide fault tolerant design automatically and (2) to ensure autonomous functional recovery for these devices after an occurrence of unavoidable damage caused by extreme radiation, temperature or simple malfunctions (e.g. severe electric transients, etc).
The way this research investigates faults differs from the conventional way of Fault Tolerance mentioned above. In this research, we will be interested in faults that can occur within the VRC, instead of focusing on environmental problems such as temperature, extreme radiation, etc. The role of fault tolerance is to deal with errors, caused by faults, before they lead to failure. This research describes about the logic simulation tool used to perform the fault simulation. AUSIM: Auburn University SIMulator was very useful in testing the architecture of Virtual Reconfigurable Circuit. It aids in debugging a circuit or in analyzing a circuit in terms of area and performance metrics. The Hardware Description Language (HDL) for AUSIM is Auburn SimulationLanguage (ASL).

VIRTUAL CONFIGURABLE CIRCUIT
The fault Tolerant System is evolved using the idea of VRC on FPGA [2] .when the VRC is uploaded in to the FPGA then its configuration bit stream determines Processing Elements (PEs) function and the places where its inputs are connected. The main advantage is that the array of PEs, the routing circuits and the configuration memory can be designed exactly according to the requirements of a given application.
VRCs require more recourses than the other common approaches used to implement a given function in an FPGA, it is realistic to suppose that their use will yield less reliable solutions. Implementation of a circuit costs a few equivalent gates in an FPGA. However, several hundred gates have to be activated if a VRC is utilized. The Pessimistic scenario says that the reliability will be decreased one hundred times in the case of use of the VRC. Hence decided to perform experiments using AUSIM simulator before physical devices will be utilized [3] .
The VRC designed for this Evolvable Fault Tolerant system consists of 25 Processing Elements (PEs) and are arranged in 4 rows and 6 columns with one output PE. The general structure of VRC is shown in Fig. 1.
Each PE consists of multiplexers and a set of functions. The routing circuits are created using multiplexers. Figure 2 represents the internal structure. Each PE can accept two, 8 bit inputs and produce a single 8-bit output.  It is a primary concern for a designer who tests a system for its ability to tolerate against faults induced into its hardware resources, to accurately specify the possible nature of faults that may occur and how they can be effectively modeled into the system under test.
In order for the system to meet all the constraints required by fault tolerant applications [4] , it is imperative for all selected Processing Elements (PEs) in the VRC to converge. Therefore, it is obvious that the most destructive scenario for the functionality of the system is to cope with the stuck-at faults that can occur in PEs (Table 1).

CIRCUITS EVOLVED IN VRC
Input from the environment enters VRC via the input interface. The architecture configuration bits determine VRCs architecture. The VRC outputs a value according to the input and its architecture bit streams. A circuit evolved that averages the (three) sensor input when all the three sensors are faultless is shown in Fig. 3.
When one of the input sensors fails as open circuit, then the optimal circuit evolved will find out the average of the remaining two inputs. The circuit evolved in this case is shown in Fig. 4. When two sensors fail as short circuit, then the optimal circuit evolved will provide the remaining one input as output, as shown in Fig. 5.

FAULT SIMULATION TOOL -AUSIM
AUSIM: Auburn University Simulator is intended for the simulation of large circuits in terms of advanced  [5] .
ASL: Auburn Simulation language is the hardware Description Language for AUSIM. The Auburn Simulation Language (ASL) description is a positional notation HDL for digital logic [6] . The ASL description represents a textual description of the circuit and requires explicit reference to a given gate or net. It consists of a single "circuit statement" and one or more component statements". The circuit statement includes the name of the complete logic circuit, its primary inputs, and its primary outputs. Once the logic diagram has been completely specified with unique gate and net names, the circuit and component statements can be generated directly from the information in the logic diagram. The ASL file is named as:

file_name.asl
Control file: The control file basically gives an ordered list of commands. The syntax of control file is: ausimcont_file_name Where the cont_file_name is the name of the control file containing the commands to AUSIM for directing the desired simulation. To begin the files must be specified. If proper naming convention is used then the user can simply enter one line: defaultfile_name This assumes that the required input files are named as file_name.asl, file _name.vec, file_name.lib. If no library file is being used then an empty file or a file with syntactically correct commentline in it will do.

Fault simulation commands:
The fltgen and bftgen commands generate gate-level stuck-at and bridging fault lists, respectively, and writes the list to the .flt file. Normally the fltgen command produces a collapsed fault list but the uncol command preceding the fltgen command will result in the generation of an uncollapsed fault list.
The notrip command is used to continue fault simulation of the following its initial detection. In this case the .det file information includes all vectors and primary outputs of the circuit for which the fault was detected [7] . The notrip command works only with serial fault simulation. Both serial and parallel fault simulation are supported for both gate-level stuck-at and bridging faults. The serial and parallel gate-level stuck-at fault simulation commands are fltsim and pftsim, respectively. The serial and parallel bridging fault simulation commands are bftsim and pbfsim, respectively. Note that only one type of fault simulation command should be included in a control file.
The fltpro command produces .pro output files which gives a profile of the fault detection associated with a given set of test vectors for the circuit begin simulated in terms of the number of faults detected by a given vector along the cumulative number of faults detected at that point in the set of test vectors.

FAULT SIMULATION RESULTS
Circuit that averages three sensor inputs: The fault simulation results for the optimal circuit evolved when all the three sensors are faultless are given below.