Journal of Electronic Testing (2019) 35:201–214https://doi.org/10.1007/s10836-019-05783-2

A Unified Approach to Detect and Distinguish Hardware Trojansand Faults in SRAM-based FPGAs

Omid Ranjbar1 · Siavash Bayat-Sarmadi1 · Fatemeh Pooyan1 ·Hossein Asadi1

Received: 29 November 2018 / Accepted: 22 February 2019 / Published online: 5 March 2019© Springer Science+Business Media, LLC, part of Springer Nature 2019

AbstractIn recent years, confrontation with hardware Trojans has become a major concern due to various reasons includingoutsourcing. Such a growing threat is more pronounced in reconfigurable devices as they are used in widespread applicationsdue to low design cost and short time-to-market. Besides their vulnerability to hardware Trojan attacks, SRAM-basedreconfigurable devices are also significantly susceptible to faults originated by particle strikes. There have been variousmethods to mitigate either hardware Trojan attacks or faults. To our knowledge, however, no method has been presentedthat can integrate detecting, distinguishing, and mitigating faults and Trojans. In this paper, we present an efficient methodfor SRAM-based reconfigurable devices, which is able to perform Trojan detection while detecting and correcting bothpermanent faults (faults in SRAM configuration bits) and transient faults (faults which affect flip flops, logical elements, andwires) using a single controller circuitry. The efficiency of the proposed method is evaluated with a well-known benchmarkimplemented on commercial FPGAs. The results show that the availability and reliability of the proposed method aresuperior to the conventional triple modular redundancy method by more than 100%. The experiments also show that theproposed method improves the average area and area×delay overheads by 32% and 6%, respectively.

Keywords Hardware trojan · Trusted design platform · Fault detection · FPGA

1 Introduction

The great importance of hardware security and trust insafety-critical applications such as military and econ-omy has resulted in significant research work in recentyears [42]. Confrontation with hardware Trojans hasbecome one of the notable parts of hardware securityand trust. Therefore, it has become essential for hardware

Responsible Editor: S. Bhunia

� Siavash Bayat-Sarmadisbayat@sharif.edu

Omid Ranjbaroranjbar@ce.sharif.edu

Fatemeh Pooyanpooyan@ce.sharif.edu

Hossein Asadiasadi@sharif.edu

1 Department of Computer Engineering, Sharif Universityof Technology, Tehran, Iran

designers to pay attention to the Trojan issue as well as faulttolerance specially in safety-critical systems. SRAM-basedField-Programmable Gate Arrays (FPGA) are amongst themost vulnerable devices to faults [6, 7]. Besides, the everincreasing application of reconfigurable devices has madethem an attractive candidate for Trojan insertion.

Employing Trojan detection methods may affect perfor-mance of applied fault tolerance schemes on the circuit. Anoccurred fault in the circuit may be mistakenly detected as aTrojan by a Trojan detection method. Furthermore, employ-ing both fault detection and Trojan detection approachesseparately can impose considerable overhead. Consideringall mentioned issues, it is important to design a method,which detects and distinguishes both faults and Trojans.

Considering different hardware platforms and varioustypes of Trojans, many studies have been carried out inrecent years. These studies can be categorized accordingto different aspects including operational time of detectionand Trojan impacts on the target circuit. Based on timeof detection, these studies can be divided into two groups:test-time methods [3, 12, 13, 23, 27, 38, 39, 43] andexecution-time (run time) methods [2, 4, 5, 9, 15, 18, 21, 31,32, 34, 36]. Run-time detection methods can be used as a

202 J Electron Test (2019) 35:201–214

Circuit is operating normally Trojan

Activation C2

Fault Occurrence

C1

Trojan detection method

Fault detection method

Both C1 and C2 are

detected as Trojan

Both C1 and C2 are

detected as fault

Trojan detected

Fault detected

Proposed method

Fig. 1 The ability of the proposed method to distinguish faultoccurrence and Trojan activation

complement for the test-time methods [18]. An undetectedTrojan in the test time could be activated during in-fieldoperation and lead to failure.

Considering the second aspect (activities of Trojansand their impacts on the target circuits) two categoriesare available: 1) functional and 2) parametric. In the firstcategory, the logical functions of the circuit are analyzedto detect any suspicious activities [12, 38, 39]. Some ofthese approaches use fault tolerant techniques to achieveTrojan detection [4, 5, 9, 15, 21, 28, 30–32, 34, 36].In these approaches, usually both Trojans and faults areassumed to be the same if they lead to failure. In thesecond category, Trojans are detected through analyzingthe circuit parametric features such as power, temperature,and delay [3, 13, 18, 23, 27, 43]. Trojan detection inreconfigurable circuits has been considered in [4, 16, 22, 24,25, 28–30, 37, 47].

In this paper, we present an efficient method thatcan integrate detecting, distinguishing and mitigating bothTrojans and faults using a reconfigurable platform alreadydesigned for detecting and correcting faults [19]. Theproposed method can detect hardware Trojans as wellas detect and correct faults using resemblances anddifferences between Trojans and faults. The ability of

the proposed method to distinguish fault occurrence andTrojan activation is illustrated in Fig. 1. This run-timemethod targets to detect functional Trojans inserted in thedelivery procedure of bitstream to customer (as illustratedin Fig. 2).

In the proposed method, the detection mechanism isbased on duplicating the main circuit in order to comparethe primary outputs and Flip-Flops (FFs) of the main andduplicated circuits. The function of the circuit would becorrected by returning to the previous clock state. Moreover,dynamic reconfiguration has been considered to correctfaults in reconfiguration bits and detect Trojans. In case ofdetecting a Trojan, the circuit is taken into a fail-safe mode.We note that, in this mode, further decisions would be madewith awareness of Trojan existence. Our proposed methoduses a similar architecture proposed in [19] to detect andcorrect faults and hence it does not impose any additionaloverhead to detect Trojans.

To evaluate the efficiency of the proposed method,by taking advantage of Xilinx Design Language (XDL)facilities, a tool is designed to implement the proposedmethod on Xilinx platform automatically. As the detailsare accessible using XDL, optimizing the performance andreducing overheads is facilitated. The proposed method hasbeen implemented on ISCAS89 benchmark [11] and isevaluated comparing to TMR. As mentioned earlier, there isno methods capable of detecting and distinguishing Trojansand faults. So, TMR is a prior candidate as it detectsfault occurrence through spatial redundancy. Implementingthe proposed method on Virtex-II has imposed 165%average area overhead while this overhead is 241% forTMR. In other words, the average area overhead ofthe proposed method is improved by 32% comparedto TMR. Also, it is observable that implementing theproposed method improves average area-delay productby 6% compared to TMR. Finally, the most significantdifference is that the circuit using TMR technique is notcapable of distinguishing fault occurrence from Trojanactivation. Availability and reliability of the proposedmethod are determined by simulating fault occurrenceand Trojan activation. Simulation results show that theavailability and reliability are superior to TMR by morethan 100%.

Fig. 2 Trojan insertion scenario

010101010101010

010001010101010

AdversaryDesigner Costumer

FPGA

J Electron Test (2019) 35:201–214 203

The contributions of this paper are summarized below:

– Introducing a unified scheme for detecting and distin-guishing faults occurred in flip flops and wires (con-sidered as transient faults), faults occurred in LUTSRAMs (considered as permanent faults) and activatedTrojans. This unification of detecting and distinguish-ing faults and Trojans, helps preventing mistakenlyreported faults and Trojans. Further, it imposes lessoverhead comparing to separate implementation of faultdetection and Trojan detection schemes. To the best ofour knowledge, no previous study has proposed such aunified detection scheme. (The circuit output is stoppedin case a Trojan activation is detected.)

– Developing a tool for proposed scheme which wouldaccelerate future research. The tool also facilitatescomparison of the proposed scheme performance ondifferent platforms and for different types of circuits(currently targeted for the Virtex II Xilinx FPGAfamily). The tool employs BLIF description for circuitresources manipulation and XDL description for circuitduplication and placement.

– Introducing and evaluating a new assessment methodfor Trojan detection with defining reliability andavailability in presence of Trojan. The evaluationis performed using Monte-Carlo method for faultoccurrence and Trojan activation simulation. Markov-Renewal model is used to simulate different statesand transition delays. The availability and reliabilityof each case is then measured and compared againstTMR.

– Area overhead (in terms of number of utilized slices)is 165% and 241% for proposed method and TMR,respectively. The average delay overhead (measuredbased on minimum possible clock cycle) is 39% forthe proposed method and 12% for TMR. The proposedmethod imposes more delay overhead due to using amore complex controller.

The rest of this paper is organized as follows. Section 2provides preliminary information regarding Trojan. InSection 3, the proposed method is explained. In Section 4,simulation results are presented. Section 5 provides somediscussion regarding the proposed method and related work.Finally, Section 6 offers the conclusion and suggestions forfuture work.

2 Preliminary

Trojans include some changes imposed to the main circuitby attackers. The purpose of inserting a Trojan is perceivingsome important data such as encryption keys throughleakage, causing disturbance in systems, or a combination of

both. Hardware Trojans usually affect logical functionalityof the circuit or its parameters such as power and delay.

2.1 Trojan Classification

As shown in Fig. 3, Trojans can be classified based onphysical characteristics, activation methods, and insertiongoals. Regarding physical characteristics, Trojan circuitplacement may be distributed or it can be placed ona specific area on the chip. Based on structure, Trojaninsertion may change the layout or leave it as it is. Also, boththe size and the type of the Trojan can be investigated asits physical characteristics. Regarding activation methods,Trojans fall into two groups: in the first group the Trojanis activated internally and in the second group, an externalsignal activates the Trojan. Finally, the intention of Trojaninsertion can be conveying important data, changing thefunction and changing the parameters of the circuit. Hatchedboxes indicate Trojans which are detectable by the proposedmethod.

2.2 Trojan and Fault

Functional Trojans can manipulate the function of the targetcircuit. These Trojans are activated in a specific state or at apredefined point of time. The impact of a functional Trojanis similar to that of a fault occurrence, changing the functionof the circuit. However, fault occurrence is a stochastic eventbut Trojan activation is based on a specific logic guided byan attacker. Finally, it is important to consider both Trojaninsertion and fault occurrence for circuits implemented onreconfigurable devices to maintain the circuits security andreliability.

3 ProposedMethod

Methods for detecting hardware Trojans may mistakenlyreport fault occurrence as a Trojan. It is also possible fora fault detection method to mistakenly report a Trojanas a fault. As mentioned earlier, to the best of ourknowledge, there is no method which is capable to integratedetecting, distinguishing and mitigating Trojans and faultsall together. The main motivation for this work is topropose an efficient method for detecting Trojans, whichcan distinguish between a Trojan and a fault. Details ofthe proposed method will be explained in the followingsections.

3.1 Trojan Insertion Assumptions

In this section, some assumptions considered in this workare described. The proposed method can handle all hatched

204 J Electron Test (2019) 35:201–214

Fig. 3 Trojan taxonomy in theliterature [26] Hardware Trojan

Classifica�on

Physical Characteris�cs

Ac�va�on Characteris�cs

Ac�on Characteris�cs

Transmit Info.

Parametric Modifica�on

Func�onal Modifica�on

Change

Disable

Externally Ac�vated

Internally Ac�vated

Antenna

Sensor

Always-On

Condi�onal

SensorLogic

Placement

Structure

Size

Type

Func�onal

Parametric

Layout Same

Layout Change

boxes shown in Fig. 3. Trojan circuit is composed of twoparts: trigger and payload [44]. A Trojan is activated by thetrigger output signal propagation towards payload. Everychange in the logical function of the circuit caused by aTrojan is similar to the effect of an error (the result of faultoccurrence) on the circuit. Therefore, it can be guaranteedthat if a functional Trojan is added to the main circuit, itslogical activities will be discernible.

Trojan insertion is performed in various ways, includingchanging one or more bits of configuration bitstream

related to one or more Look-Up Tables (LUTs) or changingrouting elements and contents of the FFs. Figure 4 providesexamples for two mentioned types of Trojans based oneither overlapping the main circuit or being outside of thecircuit. In the figure, inserted Trojan using LUT(B) uses themain circuit resources and the one using LUT(A) is outsideof the main circuit. The work presented in [14] also providesan example for a Trojan inserted using resources external tothe main circuit. These manipulations can affect the outputsof the circuit. Therefore, a functional Trojan is detectable

Fig. 4 Possible locations forTrojan insertion

Circuit

FPGA

0101010111001100

0101010110001100

Manipulated Configuration Bits

LUT4 (B)

LUT4 (A)

J Electron Test (2019) 35:201–214 205

using fault detection methods, which are based on checkingthe correctness of outputs. The proposed method is capableof detecting both types of Trojans.

The Trojan insertion process may be varied based onhardware platforms. In our proposed method, reconfig-urable devices are chosen as the target implementationplatform. Considering high security of FPGA productionprocess, attackers mostly insert Trojans through infectingconfiguration bitstreams. In this study, it is assumed that thebitstream is generated trustfully; however, it is delivered viaan unsecured channel where it is manipulated by attackers.

3.2 Architecture of the ProposedMethod

As shown in Fig. 5, the main circuit is duplicated in order toperform comparison for the primary outputs and all FFs inthe design. An HFF is added beside every main FF to save itsprevious clock value. The controlling part of the circuit is incharge of selecting the outputs of either main FFs or HFFs.The controller compares all FFs of the main circuit with thecorresponding FFs in the duplicated circuit and generatesa signal which indicates whether the circuit is operatingcorrectly or not. If any inconsistencies happen (i.e., at leasttwo paired FFs are inconsistent), it is assumed that a faultis detected and needs to be corrected. This process is doneby selecting the HFFs holding the previous clock values ofcorresponding main FFs. We note that the circuit inputs aresaved in FFs to feed the circuit with correct inputs whilereturning to the previous clock state [19].

For multiple concurrent fault occurrences, the controllersenses the inconsistency unless faults occur in the same ele-ments of the main and duplicated circuits. The probability ofsuch a pattern of fault occurrence is assumed to be negligi-ble. The only situation in which the system is able to detect

a fault but cannot correct it is when both an FF and its cor-responding HFF are affected (e.g., by a fault) in the samemanner. In this case, the controller detects inconsistency intwo consecutive clock cycles. The probability of such situa-tion is also assumed to be negligible. Besides, as discussedin [19], placement policies can help eliminate the effectof such fault occurrences. Returning to the previous clockstate, two situations can happen: A) the controller does notindicate failure; B) the controller indicates failure again.The detection process is shown in Fig. 6. If a fault occursin FFs, logic gates or circuit wires, returning to the previousclock state corrects the error. However, if an fault occurs inconfiguration bits, it would not be corrected by returning thecircuit to the previous clock state (any change in configura-tion bits is similar to changing the loaded bitstream). In thissituation, the circuit needs to be reconfigured dynamically.

It is possible that the inconsistency still exists even afterreconfiguration. Also, sequential Trojans cause predefinedpatterns of inconsistency occurrence in the circuit. In thesesituations, it is implied that there is a difference betweenthe loaded bitstream of the main and the duplicated circuitsand Trojan existence will be reported. Considering any faultdetection mechanism, Trojan activation causes entering fail-unsafe state in which the system may remain in an infiniteloop of reconfiguration.

3.2.1 Analyzing the Method in the Presence of Faults

FFs are among vulnerable elements of FPGAs to errors andtheir values would change by fault occurrence. If a faultoccurs in an FF, the controller detects the value change andcorrects it by selecting HFFs. As HFFs keep the previousclock value of the corresponding main FFs, selecting themwill return the circuit to the previous clock state. Hence,

Fig. 5 The overall view of theproposed method based on faultmitigation technique presentedin [19]

LUTQ

FF

HFF

Q

Controller state

machine

MU

X

Comparator

LUT

Q

LUT

MUX select

LUTQ

FF

HFF

Q MU

X

Q

LUT FF

HFF

Q MU

X

Q

LUT FF

HFF

MU

X

Reconfiguration

206 J Electron Test (2019) 35:201–214

Fig. 6 Operational procedure ofthe proposed method Normal

Operation

Failure!

Return the circuit to its

previous stateIs Circuit function

confirmed?

ReconfigurationIs Circuit function confirmed?

Trojan is detected

Co

rrecti

on

in

User

Bit

s a

nd

Wir

esC

orr

ecti

on

in

Co

nfi

gu

rati

on

Bit

s

Is sequential Trojan activation pattern detected?

the incorrect value will be corrected. The same process isperformed to correct faults in logic gates or wires.

This study is focused on SRAM-based FPGAs, which aremost common in the market. SRAM-memories are widelyused in LUTs, switch boxes and other resources. In case ofa fault occurrence in an LUT, the error impact is transferredto FFs and in turn the error is detected. The circuit is thenreturned to the previous clock state but the error impact stillremains in the LUT and a failure is reported again. At thispoint, a state machine, which keeps track of defined patternsof inconsistency occurrence, activates reconfiguration. Thefault in the LUT is corrected through reconfiguration andthe circuit continues its normal operation.

3.2.2 Analyzing the Method in the Presence of Trojans

Combinational Trojans are activated by providing specificinputs to the trigger circuit. If such a Trojan is activated,the circuit will encounter inconsistencies and the controllerselects to return to the previous clock state. After reachingthe initial faulty state, the previous values are appliedto trigger inputs; therefore the Trojan is activated again.The controller state machine reaches reconfiguration stateand announces that the circuit needs to be reconfigured.If multiple Trojans are inserted, the controller senses theinconsistency unless same Trojans are inserted in the sameelements of the main and duplicated circuits. This patternof Trojan insertion is nearly infeasible without the use ofreverse engineering. Therefore, an inserted Trojan activationis detectable in both circuits.

Even after reconfiguration, the Trojan remains active andaffects the circuit functionality. At this point, controller statemachine enters Trojan detection state and it is concludedthat the circuit is infected by Trojans. Having such stateprevents the circuit entering a fail-unsafe mode that resultsin repeating the reconfiguration process.

Sequential Trojans are more complex than combinationalones since they constitute a state machine. When this statemachine reaches one or more specific states, the Trojanwill be activated. Here, two cases of sequential Trojans willbe analyzed: A) Trojans that use FFs of the main circuitand B) Trojans that are composed of unused FFs (refer toSection 3.1 and Fig. 4).

If the activated Trojan includes main circuit FFs, byreturning to the previous clock state, the trigger statemachine loads the previous clock values using HFFs. Afterreaching the initial faulty state, the Trojan activates again.The Trojan activation pattern is the same as combinationalTrojan and it is detected after reconfiguration. Even in caseof using HFFs as Trojan components, the Trojan can bediscerned in the same way.

If the Trojan includes FFs other than the main circuitFFs, the temporary impact of the Trojan is corrected afterreturning to the previous state because there is no HFF tokeep the previous clock value of the Trojan state machine.However, the circuit would not pass incorrect outputs andhence the system would not enter an unsafe mode in thissituation.

Figure 7a shows a Trojan inserted inside the main circuit.The Trojan is activated in state 2. In the nth clock cycle

J Electron Test (2019) 35:201–214 207

0 1 2 3

3H2H1H0Hclk=n

0 1 2 3

clk=n+1

0 1 2 3clk=n+2

3H2H1H0H

3H2H1H0H

0 1 2 3

0 1 2 3

0 1 2 3

clk=n

clk=n+1

clk=n+2

(a)

(b)

Fig. 7 Sequential Trojan: a Trojan using FFs of the main circuit, bTrojan using unused FFs without history

(clk=n), the circuit is in state 2 and the Trojan is activated.Therefore, in clk=n + 1 the controller selects HFF2 (whichholds the value of FF2 at clk=n − 1) and Trojan is inactive.In clk=n + 2, the circuit again reaches the state of clk=n; sothe Trojan becomes activated again. This pattern of Trojanactivation (activated, not activated, activated) is detected bythe controller state machine.

In Fig. 7b, the Trojan uses FFs other than the main circuitFFs and no history is saved for the state machine. The Trojanis activated just in clk=n; so the activation pattern doesnot match the mentioned pattern (activated, not activated,activated) and the Trojan activation is detected as a faultoccurrence. To confront such Trojans, three solutions aresuggested that will be detailed next.

A) Using fault rate approximation: In this solution, wedefine a limit based on assumptions of fault occurrencerate to recognize suspicious events. These assumptionsare made according to statistical data analysis. Forexample, if the period of fault occurrence is consideredas three months, two situations are possible. If the Tro-jan is activated during this period, it is recognized asa suspicious event so the Trojan is discerned. In the

second situation, the period of Trojan activation isequal to or greater than fault occurrence period. In thiscase, Trojan activation can be disregarded since it hasinsignificant impact on the performance of the circuitand would not cause passing incorrect outputs. In thiscase, Trojan is not detected using this solution.

B) Providing HFFs for unused FFs: In this solution,each pair of unused FFs of the circuit are joined toform a main-history pair. Using this solution, all typesof sequential Trojans are detectable.

C) Filling up the whole circuit: Here, the whole circuitis filled up so that the attacker cannot insert Trojansthat include unused elements of the circuit. Clearly,the inserted dummy logic has to be independent fromthe main circuit. A work similar to this methodis presented in [24], which is designed to preventTrojan insertion through filling the circuit. However,manipulation of the used resources is not consideredin [24].

4 Experimental Setup and Tools

In this section, the implementation of the proposed methodis presented. XDL has been used to implement an automatictool. XDL provides efficient facilities to manipulate thelogical and routing resources of reconfigurable circuitdesigns. Verilog Hardware Description Language (HDL)and Berkeley Logic Interchange Format (BLIF) [10] are alsoused in different stages of the implementation. We note thatABC tool [1] is used to generate BLIF files.

Figure 8 shows the operational diagram of the proposedtool. It is designed based on the architecture of XilinxVirtex II (xc2v4000ff1517-6) [46]. Synthesis, placement,and routing steps are performed using Xilinx ISE Design10.1 package tools [46]. XDL tool of ISE package isused to convert .ncd files to .xdl files and vice versa.Netgen tool [35] is also used to simulate the proposedmethod and to convert .ncd files to Verilog HDL. Circuitdelays are measured by Xilinx ISE Timing Analyzer [46].Figure 9 shows the post-placed and routed view of s38417circuit implemented using this tool on the target device.It is worth mentioning that although Vivado design suitdoes not support the XDL, it is possible to implementsuch methodology using the TCL script and make Vivadocompatible with XDL [40].

4.1 Fault and Trojan Simulations

Availability and reliability of the design are two importantcriteria used to evaluate the proposed method. To the bestof our knowledge, previous work in this area has not beenevaluated by these two criteria considering both faults and

208 J Electron Test (2019) 35:201–214

Fig. 8 Operational flow of theproposed tool High level circuit

descriptionin Verilog

BLIF file generation using

ABC tool

Synthesis and placement and

routing

Exploiting resources

Adding HFFs and controller

Converting BLIF to Verilog

NCD file generation

Exploiting resources

Circuit duplication

New placed and routed circuit

Bitstream

ncd2xdl

Trojans. Here, we calculate availability and reliability byfaults and Trojans simulations. The Markov model [17] isnot accurate enough to simulate both faults and Trojans.Since it is based on exponential rates while repair operationis performed in almost constant time. Considering this fact,the Markov-Renewal model [8] has been used.

Figure 10a shows the Markov-Renewal model of theproposed method. In the initial (Normal) state, the systemoperates normally. Fault occurrence or Trojan activationalters the operational state of the system. In case of faultoccurrence, the state changes to Recovery Mode 1 andthe circuit is repaired by returning to the previous clock.

Fig. 9 Post-placed and routed view of s38417 circuit imple-mented using the proposed automatic tool on a Xilinx Virtex II(xc2v4000ff1517-6)

The repair time is very short so that the operational statechange would not be observable. If the fault is not repairedyet, reconfiguration is performed and the state changes toRecovery Mode 2. In this condition, the system is repairedin constant repair time and the normal operation is thenresumed. Repair time duration depends on reconfigurationtime that is almost constant. The term “Tr. Rate” is usedto determine the Trojan activation rate. The system enters

Normal2-OK

Tr. Rate

F. Rate for 3 module

1-OKF. Rate for 2 module

Rec. Time

Tr. Rate

Trojan!Failed Unsafe

(b)

Normal

Trojan!Failed Safe

Recovery Mode 2

Recovery Mode 1

Tr. Rate

F2. Rate

F1. Rate

R2. Time

(a)

R1. Time

Fig. 10 Markov-Renewal model: a Proposed method, b TMR

J Electron Test (2019) 35:201–214 209

Trojan detection state and its operation terminates in fail-safe mode when a Trojan is observed in the circuit.

Evaluation of the proposed method is done by comparingit with TMR method as a baseline. Figure 10b shows theMarkov-Renewal model of TMR. The system is operatingnormally while it is in Normal state. By the first faultoccurrence, the system state changes to OK-2. In this state,the system can continue its normal operation with twoworking components and any fault occurrence changes thestate to OK-1. Then, the system enters Normal state in aconstant repair time. In TMR, unlike the proposed method,the impact of a fault occurrence in OK-2 state is notobservable at the right time and it may take a large numberof clock cycles to be detected. Since there is no HFF inTMR to store the previous clock state of the system, thescheme needs a long time to recover its previous state inaddition to repair time (reconfiguration time). This recoverytime depends on the intervals of the checkpoints (time spotswhen the system state is stored). Therefore, the repair timeof TMR is longer than the proposed method.

In TMR, within each of the two states that the systemis operating normally, an inserted Trojan can be activatedand perform its malfunction. The circuit would not produceany incorrect outputs in most cases but since TMR does nothave the ability to distinguish Trojans, the system continuesits operation in a wrong state with no insight into Trojanexistence. It can be hazardous in critical applications.

In order to measure the reliability and availability ofthese two methods, a tool has been developed using Javathat can perform fault and Trojan simulations. The faultinjection and the Trojan insertion simulations have beenperformed using Monte-Carlo [33] simulation algorithm.The simulations have been repeated a 1000 times fordifferent Trojan activation and fault occurrence rates.Occurrence of a fault is considered as an exponentialevent. Trojan is considered combinational and the activationdistribution is memoryless (due to the unpredictabilityof activation time and being independent from previousactivation time). Therefore, activation distribution of Trojanshould be exponential.

Availability and reliability of each method have beenmeasured by simulating three different rates of Trojanactivation and fault occurrence. First, the rate of Trojanactivation and fault occurrence are the same (10−5 tr/h,10−5

f/h). Second, the rate of fault occurrence is higher thanTrojan activation rate (10−5 tr/h,10−3 f/h). Finally, the rateof Trojan activation is higher than fault occurrence rate(10−3 tr/h,10−5 f/h), where tr/h and f/h determine Trojanactivation and fault occurrence rate per hour, respectively.Repair time varies among circuits with different workingfrequencies. It also depends on the device reconfigurationtime and accordingly on frequency of loading each bitand area. In this work, the clock period is set to 10ns

and reconfiguration time is considered 10ms (for Virtex IIdevice) for the simulated benchmarks.

Results of availability measurements for three mentionedcases are shown in Fig. 11. It is observable that theavailability of the proposed method is higher than that ofTMR. We note that TMR is evaluated in two cases. Inthe first case, the interval between check points is oneclock cycle (CHK1) while in the second case a check pointis saved every 1000 clock cycles (CHK2). It should benoted that TMR cannot detect fault occurrence immediately

1.024446852

6.0090972952.243133117

7.0637244

5.210023613

15.82886525

0

2

4

6

8

10

12

14

16

18

20

200 400 600 800 1000 1200

UN

AVAI

LABI

LITY

(X 1

0-3)

SIMULATION HOURS

Proposed TMR-CHK1 TMR-CHK2

(a)

1.006986165

5.966975683

1.301363598

6.302857491

1.711553595

7.430107454

0

1

2

3

4

5

6

7

8

9

10

200 400 600 800 1000 1200

UN

AVAI

LABI

LITY

(X 1

0-3)

SIMULATION HOURS

Proposed TMR-CHK1 TMR-CHK2

(b)

0.95365115

5.932574561

1.373666468

6.404963657

1.701460616

6.720018414

0

1

2

3

4

5

6

7

8

9

10

200 400 600 800 1000 1200

UN

AVAI

LABI

LITY

(X 1

0-3)

SIMULATION HOURS

Proposed TMR-CHK1 TMR-CHK2

(c)

Fig. 11 Availability comparison: a same Trojan activation and faultoccurrence rate, b higher fault occurrence rate, and c higher Trojanactivation rate

210 J Electron Test (2019) 35:201–214

because the comparison is performed on final outputs unlikethe proposed method, which also compares all FFs outputs.Additionally, TMR circuit would not function correctlyright after a fault is detected. The circuit needs to loadthe values of checkpoints to reach the last correct state.Simulation results for TMR with checkpoints interval ofone clock cycle appears to be acceptable; however, this caseimposes a large overhead.

Figure 11a shows the case that the rate of fault occurrenceis higher than Trojan activation rate. In this case, (after1200 simulation hours) the availability of the proposedmethod is superior to TMR-CHK1 and TMR-CHK2 by118% and 263%, respectively. Figure 11b compares theavailabilities of the methods for equal Trojan activation andfault occurrence rates. Similarly, in this case, the availabilityof the proposed method is 106% and 124% higher thanTMR-CHK1 and TMR-CHK2, respectively. Figure 11c alsoshows the condition that the rate of Trojan activation ishigher than fault occurrence rate. Here, the availabilityof the proposed method is 108% and 113% higher thanTMR-CHK1 and TMR-CHK2, respectively.

Figure 12 shows the results of reliability evaluationfor three mentioned cases of Trojan activation and faultoccurrence rates. We have considered a system to be reliableonce it becomes operational right after the repair anddoes not produce wrong outputs. So, TMR is not reliableafter reconfiguration. The reason is that in case of faultoccurrence in TMR, system stops all operations until itreaches the last normal state. This suspension in the normaloperation of the system reduces the reliability. Hence, thereliability of the proposed method is always higher thanTMR. In particular, this superiority is more apparent in thecondition that the rate of fault occurrence is higher thanTrojan activation rate as shown in Fig. 12a. In the proposedmethod, returning to Normal state is performed quickly atthe time of fault occurrence. In the other two cases, shownin Fig. 12b and c, the reliability of the proposed methodafter 1200 simulation hours is higher than TMR-CHK1 by120% and 106% and is higher than TMR-CHK2 by 136%and 111%, respectively.

4.2 Overheads

To evaluate the area overhead in the Xilinx FPGA, wehave compared the number of utilized slices between theproposed method and TMR. Figure 13 shows that in theproposed method, average utilization of slices is increasedby 165% and it is less than 241% for TMR. Slices utilizedby hffs, the controller and the duplicated circuit cause thearea overhead of the proposed method. We note that theproposed method uses more FFs. This may impose moreslice utilization compared to TMR in circuits with greaterratio of FFs to logic elements.

0.963489402

5.927711457

32.186888

405.9390013

32.35108888

406.782

0

50

100

150

200

250

300

350

400

450

500

200 400 600 800 1000 1200

UN

RELI

ABIL

ITY(

X 10

-3)

SIMULATION HOURS

Proposed TMR-CHK1 TMR-CHK2

(a)

1.006985152

5.966974689

1.993032807

7.15626014

3.00360904

8.13793832

0

1

2

3

4

5

6

7

8

9

10

200 400 600 800 1000 1200U

NRE

LIAB

ILIT

Y(X

10-3

)

SIMULATION HOURS

Proposed TMR-CHK1 TMR-CHK2

(b)

0.9536511

5.9325746

1.273666468

6.304963657

1.601460616

6.620018414

0

1

2

3

4

5

6

7

8

9

10

200 400 600 800 1000 1200

UN

RELI

ABIL

ITY(

X 10

-3)

SIMULATION HOURS

Proposed TMR-CHK1 TMR-CHK2

(c)

Fig. 12 Reliability comparison: a same Trojan activation and faultoccurrence rate, b higher fault occurrence rate, and c higher Trojanactivation rate

The delay of a sequential circuit is equal to its minimumpossible clock period. Circuit delays are computed usingTiming Analyzer. Figure 14 illustrates that the average delayoverhead is 39% for the proposed method and 12% forTMR. This difference is mainly due to the more complexcontroller used in the proposed method. In this method,the controller gathers the outputs of all FFs of the mainand duplicated circuits and compares each pair using XORfunction. The outputs of all these XOR functions are fedinto an OR function. Finally, the OR function output is usedto indicate if any inconsistencies are found. All mentioned

J Electron Test (2019) 35:201–214 211

Fig. 13 Area overheadpercentage in terms of numberof slices

0

50

100

150

200

250

300

s27

s298

s344

s349

s382

s386

s400

s444

s510

s526

s641

s713

s820

s832

s953

s119

6

s123

8

s148

8

s149

4

s537

8

s923

4

s132

07

s158

50

s384

17

AV

G

GE

O

Proposed TMR

functions are implemented using LUTs. However, TMRcircuit detects inconsistencies by just comparing finaloutputs of its modules.

Area × delay, also known as Area-Delay Product (ADP),is a proper factor for overall overhead comparison. Asillustrated in Fig. 15, the proposed method imposes lessADP overhead compared to TMR by 6% on average. Wenote that the main superiority of the proposed methodto integrate both detecting and distinguishing faults andTrojans along with less average ADP overhead makes it aproper choice compared to previous work.

5 RelatedWork and Discussions

In [36], Trojan detection has been performed through votingbetween two identical systems. This process is applied usingdifferent Intellectual Properties (IPs) for correspondingsystems. In [21], Triple Modular Redundancy (TMR)method has been used to detect Trojans. According to thestatistical analysis, the most area-efficient tripling technique

is used. Also, OPTMR [30] and ATMR [28] use TMR withsome optimizations as a Trojan detection approach. Neitherof these methods can distinguish a fault from a Trojan.In [16], authors attempt to validate the bitstream, which isimplemented on FPGA using parity-based error correctingcodes.

In [41], an approach to detect faults in SRAM memoriesalong with protecting Trojan insertion in such circuitsis proposed. In order to prevent deterministic Trojantriggering, obfuscations of address and data are performed.Additionally, Cyclic Redundancy Check (CRC) coding isused for fault detection. This method cannot distinguishfaults from Trojans. TPAD [45] targets detecting functionalTrojans during both test time and run time. The detectionmechanism is based on concurrent error detection method.It also uses random switching to hide the logic of importantmodules from the adversary. In [24], it is claimed that byfilling the FPGA thoroughly, there is no way to insert aTrojan. However, inserting a Trojan via changing the maincircuit is not considered in [24]. In [19], fault detection andcorrection are performed by duplicating circuits and using

Fig. 14 Delay overheadpercentage

0

10

20

30

40

50

60

70

s27

s298

s344

s349

s382

s386

s400

s444

s510

s526

s641

s713

s820

s832

s953

s119

6s1

238

s148

8s1

494

s537

8s9

234

s132

07s1

5850

s384

17

AV

GG

EO

Proposed TMR

212 J Electron Test (2019) 35:201–214

Fig. 15 Area-delay productpercentage

0

50

100

150

200

250

300

350

400

450

500

s27

s298

s344

s349

s382

s386

s400

s444

s510

s526

s641

s713

s820

s832

s953

s119

6

s123

8

s148

8

s149

4

s537

8

s923

4

s132

07

s158

50

s384

17

AV

G

GE

O

Proposed TMR

History Flip-Flops (HFFs). This method has an appropriateavailability and a proper ability for only fault detectionand correction using reconfiguration. To the best of ourknowledge, no method has been proposed in the previouswork in order to detect and distinguish hardware Trojansand faults in a unified manner.

DMR scheme is intrinsically vulnerable to deliberateinconsistencies injected into a circuit. Therefore, in theproposed method, if an attacker inserts the same Trojan inthe same places of both the main and duplicated circuits,the Trojan activation would not be detected due to theunderlying DMR scheme. The probability of such patternof Trojan insertion is assumed to be very low becausethe attacker is not aware of the details of the circuit.Besides, fault occurrence in the same elements of main andduplicated circuits would not be detected by the proposedmethod. The probability of such fault occurrence is alsoassumed to be low.

Regarding occurrence of faults or insertion of Trojansin the controller circuit, we note that as discussed in [19],such faults and similarly Trojans will ultimately lead toreconfiguration of the controller circuit. If the cause is afault, the reconfiguration will fix the issue; however, incase of Trojan, the circuit keeps reconfiguring itself andafter a number of times the mechanism titled “using faultrate approximation” mentioned in Section 3.2.2 will stopthe process and alert existence of a Trojan. Alternatively,another recommendation to resolve this issue is to duplicatethe controller circuitry and use an XOR gate to comparethe resulting two alarm signals. The XOR gate can beimplemented using hard logic cores in FPGA to avoidany Trojan. Clearly, duplicating the control unit imposesextra hardware overhead. The final recommendation is toimplement the entire controller circuit using hard logic coresof the FPGA upon availability of such resources.

The proposed method improves average area overheadby 32% while the delay overhead is increased by 69%. Theimposed overhead mainly depends on the number of checkpoints. So, reducing the check point frequency of the circuitmay lead to less area and delay overhead.

6 Conclusion

This paper presents a method capable of detecting anddistinguishing Trojans and faults in a unified manner. Thedetection mechanism is based on a fault detection methodand it never produces false positives; i.e., it never detectsTrojan for circuits that operate normally. Also, a tool hasbeen developed to automatically implement this methodfor different circuits. This method is dedicated to FPGAplatforms. Simulations have been performed on Virtex IIand the results show that availability and reliability ofthe proposed method are superior to TMR by more than100%. The experiments also show that the proposed methodimproves the average area and area×delay overheads by32% and 6%, respectively. Optimizing resource allocationspecially for circuits with great ratio of number of FFsto logical elements would help reduce area overhead. Asfuture work, a tool can be developed to provide the proposedunified approach for recent FPGAs and be compatible withVivado design suite.

Publisher’s Note Springer Nature remains neutral with regard tojurisdictional claims in published maps and institutional affiliations.

References

1. ABC: A System for Sequential Synthesis and Verification.[Online]. Available : https://people.eecs.berkeley.edu/alanmi/abc

J Electron Test (2019) 35:201–214 213

2. Abramovici M, Bradley P (2009) Integrated circuit security newthreats and solutions. In: Proc of the 5th Annual Workshop onCyber Security and Information Intelligence Research: CyberSecurity and Information Intelligence Challenges and Strategies,New York, pp 1–3

3. Agrawal D, Baktir S, Karakoyunlu D, Rohatgi P, Sunar B(2007) Trojan detection using IC fingerprinting. In: Proc of thesymposium on security and privacy, Berkeley, pp 296–310

4. Al-Anwar A, Alkabani Y, El-Kharashi MW, Bedour H (2013)Hardware trojan detection methodology for FPGA. In: Procof the Conference on Communications, Computers and SignalProcessing (PACRIM), Victoria, pp 177–182

5. Al-Anwar A, Alkabani Y, El-Kharashi MW, Bedour H (2013)Hardware trojan protection for third party IPs. In: Proc of theConference on Digital System Design (DSD), Los Alamitos, pp662–665

6. Asadi H, Tahoori MB (2007) Analytical techniques for softerror rate modeling and mitigation of FPGA-based designs. IEEETransactions on Very Large Scale Integration Systems (VLSI)15(12):1320–1331

7. Asadi H, Tahoori MB, Mullins B, Kaeli D, Granlund K (2007)Soft error susceptibility analysis of SRAM-based FPGAs in high-performance information systems. IEEE Trans Nucl Sci (TNS)54(6):2714–2726

8. A‡inlar E. (1969) Markov renewal theory, vol 19. Beaumont M, Hopkins B, Newby T (March 2012) SAFER

PATH security architecture using fragmented execution andreplication for protection against trojaned hardware. In: Proc ofthe conference on design, automation and test in europe (DATE),San Jose, pp 1000–1005

10. Berkeley Logic Interchange Format (BLIF). (1993). [Online].Available: https://www.ece.cmu.edu/ee760/760docs/blif.pdf

11. Brglez F, Bryan D, Kozminski K (1989) Combinational profilesof sequential benchmark circuits. In: Proc of the symposium oncircuits and systems, Portland, pp 1929–1934

12. Chakraborty RS, Paul S, Bhunia S (2008) On-demand trans-parency for improving hardware trojan detectability. In: Procof the Symposium on Hardware-Oriented Security and Trust(HOST), Anaheim, pp 48–50

13. Cha B, Gupta SK (2013) Trojan detection via delay measure-ments: a new approach to select paths and vectors to maximizeeffectiveness and minimize cost. In: Proc of Design, Automation& Test in Europe Conference & Exhibition (DATE), Grenoble, pp1265–1270

14. Chakraborty RS, Saha I, Palchaudhuri A, Naik GK (2013)Hardware Trojan Insertion by Direct Modification of FPGAConfiguration Bitstream. IEEE Des Test 30(2):45–54

15. Cui X, Ma K, Shi L, Wu K (2014) High-Level synthesis for run-time hardware trojan detection and recovery. In: Proc of the 51stAnnual Design Automation Conference, New York, pp 1–6

16. Dutt S, Li L (2009) Trust-Based Design and check of FPGA cir-cuits using Two-Level randomized ECC structures. ACM Trans-actions on Reconfigurable Technology and Systems (TRETS)2(1):6:1–6:36

17. Dynkin EB (1965) Markov processes. In: Markov Processes,Springer, Berlin, pp 77–104

18. Forte D, Bao C, Srivastava A (2013) Temperature tracking- aninnovative Run-Time approach for hardware trojan detection.In: Proc of the international conference on Computer-Aided(ICCAD), piscataway, pp 532–539

19. Ghaderi Z, Miremadi SG, Asadi H, Fazeli M (2013) HAFTA-highly available fault-tolerant architecture to protect SRAM-basedreconfigurable devices against multiple bit upsets. IEEE TransDevice Mater Reliab 13(1):203–212

20. Govindan V, Chakraborty RS (2018) Logic testing for hardwaretrojan detection. In: The Hardware Trojan War, Springer, Cham,pp 149–182

21. Gunti NB, Khatri A, Lingasubramanian K (2014) Realizing asecurity aware triple modular redundancy scheme for robustintegrated circuits. In: Proc of the Conference on Very Large ScaleIntegration (VLSI-soc), Playa del Carmen, pp 1–6

22. Jim P, Saqib F (2018) Detecting hardware trojans using delayanalysis, In: The Hardware Trojan War, Springer, Cham, pp219–267

23. Jin Y, Makris Y (2008) Hardware trojan detection using path delayfingerprint. In: Proc of the symposium on Hardware-Orientedsecurity and trust (HOST), Anaheim, pp 51–57

24. Khaleghi B, Ahari A, Asadi H, Sarmadi B (2015) FPGA-Based protection scheme against hardware trojan horse insertionusing dummy logic. IEEE Journal of Embedded Systems Letters7(2):46–50

25. Kitsos P, Voyiatzis AG (2014) FPGA trojan detection usingLength-Optimized ring oscillators. In: Proc of the conference ondigital system design (DSD), Verona, pp 675–678

26. Kuon I, Tessier R, Rose J (2008) FPGA Architecture: surveyand challenges. Journal of Foundations and Trends in ElectronicDesign Automation 2(2):135–253

27. Li J, Lach J (2008) At-Speed delay characterization for ICauthentication and trojan horse detection. In: Proc of thesymposium on Hardware-Oriented security and trust (HOST),Anaheim, pp 8–14

28. Mal-Sarkar S, Karam R, Narasimhan S, Ghosh A, KrishnaA, Bhunia S (2016) Design and validation for FPGA trustunder hardware trojan attacks. IEEE Transactions on Multi-ScaleComputing Systems 2(3):186–198

29. Mal-Sarkar S, Krishna A, Ghosh A, Bhunia S (2014) Hardwaretrojan attacks in FPGA devices: threat analysis and effectivecounter measures. In: Proc of the 24th Edition of the Great LakesSymposium on VLSI (GLSVLSI), New York, pp 287–292

30. Mao S, Liu L (2016) OPTMR: Optimal data flow graph parti-tioning for triple modular redundancy against hardware Trojanin reconfigurable hardware. In: Proc of the 6th IEEE Interna-tional Conference on Electronics Information and EmergencyCommunication (ICEIEC), pp 68–71

31. McIntyre D, Wolff F, Papachristou C, Bhunia S, Weyer D (2009)Dynamic evaluation of hardware trust. In: Proc of the Symposiumon Hardware-Oriented Security and Trust (HOST), Francisco, pp108–111

32. McIntyre D, Wolff F, Papachristou C, Bhunia S (2010)Trustworthy computing in a multi-core system using distributedscheduling. In Proc of the International On-Line TestingSymposium (IOLTS), Corfu, pp 211–213

33. Mooney, Christopher Z (1997) Monte Carlo simulation. Sagepublications

34. Newgard B, Hoffman C (2010) Using multiple processors in asingle reconfigurable fabric for High-Assurance applications. In:Proc of the symposium on Hardware-Oriented security and trust(HOST), Anaheim, pp 25–29

35. Open Circuit Design. [Online]. Available: http://opencircuitdesign.com

36. Rajendran J, Zhang H, Sinanoglu O, Karri R ( 2013) High-Level synthesis for security and trust. In: Proc of the internationalOn-Line testing symposium (IOLTS), Chania, pp 232–233

37. Rilling J, Graziano D, Hitchcock J, Meyer T, Wang X, JonesP, Zambreno J (2011) Circumventing a ring oscillator approachto FPGA-based hardware trojan detection. In: Proc of theInternational Conference on Computer Design (ICCD), Amherst,pp 289–292

214 J Electron Test (2019) 35:201–214

38. Roy JA, Koushanfar F, Markov IL (2008) EPIC: Ending piracyof integrated circuits. In: Proc. of the Conference on Design,Automation and Test in Europe (DATE), Munich, pp 1069–1074

39. Salmani H, Tehranipoor M, Plusquellic J (2012) A novel techniquefor improving hardware trojan detection and reducing trojanactivation time. IEEE Trans Very Large Scale Integr VLSI Syst20(1):112–125

40. Santangelo L (2014) Viv2XDL: a bridge between Vivadoand XDL based software, Master’s Thesis, University ofPisa. [Online]. Available : https://etd.adm.unipi.it/t/etd-09012014-224107

41. Senwen K, Ottavi M, Dworak J (2015) Enhancing embeddedSRAM security and error tolerance with hardware CRC andobfuscation. In Proc of IEEE International Symposium on Defectand Fault Tolerance in VLSI and Nanotechnology Systems(DFTS), pp 119–122

42. Wang X, Tehranipoor M, Plusquellic J (2008) Detecting maliciousinclusions in secure hardware: challenges and solutions. In:Proc of the symposium on Hardware-Oriented security and trust(HOST), Anaheim, pp 15–19

43. Wang X, Salmani H, Tehranipoor M, Plusquellic J (2008)Hardware trojan detection and isolation using current integrationand localized current analysis. In: Proc of the symposium ondefect and fault tolerance of VLSI systems (DFTVS), Boston, pp87–95

44. Wolff F, Papachristou C, Bhunia S, Chakraborty RS (2008)Towards Trojan-Free Trusted ICs: Problem Analysis and Detec-tion Scheme. In: Proc of the Conference on Design, Automationand Test in Europe (DATE), New York, pp 1362–1365

45. Wu TonyF et al (2016) Tpad: Hardware Trojan prevention anddetection for trusted integrated circuits. IEEE Trans ComputAided Des Integr Circuits Syst 35.4:521–534

46. Xilinx Inc. [Online]. Available : http://www.xilinx.com47. Zhang X, Tehranipoor M (2011) RON- an on-chip ring oscillator

network for hardware trojan detection. In: Proc of the Conferenceon Design, Automation and Test in Europe (DATE), Grenoble, pp1–6

Omid Ranjbar recieved his M.Sc from Sharif University ofTechnology in Computer Architecture and his B.Sc. from AmirkabirUniversity in Computer Engineering in 2015 and 2013, respectively.He is a graduate researcher with Sharif Hardware Security and Trust(HST) lab. His research interests are hardware security and trust.

Siavash Bayat-Sarmadi received the B.Sc. degree from the Universityof Tehran, Iran, in 2000, the M.Sc. degree from Sharif Universityof Technology, Tehran, Iran, in 2002, and the PhD degree fromthe University of Waterloo in 2007, all in computer engineering(hardware). He was with Advanced Micro Devices, Inc. for about6 years. Since September 2013, he has been a faculty memberin the Department of Computer Engineering, Sharif University ofTechnology. He has served on the executive and scientific committeesof several conferences. He is the founder and director of the HSST(hardware and system security and trust) Laboratory at SUT. He hasalso co-founded a startup company (NAAD), which provides solutionsco-designed by hardware/software with security in mind. His researchinterests include Cyber Physical Systems/Internet of Things, hardwaresecurity and trust, cryptographic engineering, and secure, efficient anddependable computing and architectures. He is a member of the IEEE.

Fatemeh Pooyan is pursuing her B.S. degree in Computer Engi-neering, with hardware speciality, at Sharif University of Technology,Tehran, Iran. She is a undergraduate researcher with Sharif HardwareSecurity and Trust (HST) lab. Her research interests include hardwaresecurity and trust.

Hossein Asadi received the B.S. and M.S. degrees in computerengineering from the Sharif University of Technology (SUT), Tehran,Iran, in 2000 and 2002, respectively, and the Ph.D. degree in electricaland computer engineering from Northeastern University, Boston,MA, USA, in 2007. He was with EMC Corporation, Hopkinton,MA, USA, as a Research Scientist and Senior Hardware Engineer,from 2006 to 2009. From 2002 to 2003, he was a member of theDependable Systems Laboratory, SUT, where he researched hardwareverification techniques. From 2001 to 2002, he was a member ofthe Sharif Rescue Robots Group. He has been with the Departmentof Computer Engineering, SUT, since 2009, where he is currently atenured Associate Professor. He is the Founder and Director of theDSN Laboratory at SUT. He spent three months in the summer 2015 asa Visiting Professor at the the School of Computer and CommunicationSciences at the Ecole Poly-technique Federele de Lausanne (EPFL).He has also co-founded the first startup company in the MiddleEast, called HPDS, designing and fabricating midrange and high-enddata storage systems. He has authored and co-authored more thansixty technical papers in reputed journals and conference proceedings.His current research interests include data storage systems andnetworks, solid-state drives, operating system support for I/O andmemory management, and reconfigurable and dependable computing.Dr. Asadi was a recipient of the Technical Award for the BestRobot Design from the International RoboCup Rescue Competition,organized by AAAI and RoboCup, a recipient of Best Paper Awardat the 15th CSI Internation Symposium on Computer Architectureand Digital Systems (CADS), the Distinguished Lecturer Award fromSUT in 2010, the Distinguished Researcher Award from SUT in 2016,and the Distinguished Research Insitute Award from SUT in 2016.He is also recipient of Extraordinary Ability in Science visa from USCitizenship and Immigration Services in 2008. He has also served asthe publication chair of several national and international conferencesincluding CNDS2013, AISP2013, and CSSE2013 during the pastthree years. Most recently, he has served as a Guest Editor of IEEETransactions on Computers in 2016 and a Program Co-Chair of the18th International Symposium on Computer Architecture & DigitalSystems (CADS2015).