on-chip analog trojan detection framework for ...jin.ece.ufl.edu/papers/tcad18.pdf · a. analog...

0278-0070 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCAD.2018.2864246, IEEETransactions on Computer-Aided Design of Integrated Circuits and Systems

On-Chip Analog Trojan Detection Framework forMicroprocessor Trustworthiness

Yumin Hou, Hu He, Kaveh Shamsi Student Member, IEEE, Yier Jin Member, IEEE,Dong Wu, Huaqiang Wu Senior Member, IEEE

Abstract—With the globalization of semiconductor industry,hardware security issues have been gaining increasing attention.Among all hardware security threats, the insertion of hardwareTrojans is one of the main concerns. Meanwhile, many cur-rent Trojan detection solutions follow the assumption that thehardware Trojan itself should be composed of digital logic. Thisassumption is invalidated by recently proposed analog Trojanswhich are extremely small and can detect rare events. This paperproposes a runtime hardware Trojan detection method which isgeared towards detecting such advanced Trojans. The principleof this method is to guard a set of concerned signals, and initiate ahardware interrupt request when abnormal toggling events occurin these guarded signals. To prove the effectiveness of this method,we design a processor based on ARMv7-A&R ISA, and insertan analog Trojan into the processor. We fabricated the design inan SMIC 130 nm process and demonstrate the effectiveness ofthe proposed methodology.

I. INTRODUCTION

The globalization of semiconductor industry brings criticalsecurity, integrity, and privacy concerns. The globalization ofthe integrated circuit (IC) supply chain makes it difficult andcostly for regulations only to maintain the integrity of theIC design through the design and fabrication process. Thisis especially true for the case of third party components [1].

Among all hardware security threats including reverse en-gineering, IP piracy, etc., the insertion of malicious logic (akahardware Trojans) is still one of the main concerns. Uponthis challenge, researchers from the government, industry andacademia have proposed various techniques to help identifymalicious logic both pre-fabrication, on RTL, netlist, andlayout levels, as well as post-fabrication on manufactured cir-cuits, using a combination of special testing pattern generationtechniques and side-channel analysis.

Given that most of the hardware Trojans target digitalcircuits, almost all Trojan designing methods and detection so-lutions follow the same assumption that hardware Trojan itselfshould be composed of digital logic. This assumption largelylimits the capabilities of many hardware Trojan detectionmethod in detecting digital Trojans only. Another fundamentallimitation of all the detection schemes is that the effect of

This work is supported by the National Natural Science Foundation ofChina under Grant No. 61502032, and by Tsinghua and Samsung JointLaboratory. The corresponding author is Hu He.

Y. Hou, H. He, D. Wu and H. Wu are with the Instituteof Microelectronics, Tsinghua University, Beijing, 100084, China(email: [email protected], [email protected],[email protected], [email protected]).

K. Shamsi and Y. Jin are with the Department of Electrical and ComputerEngineering, University of Florida, Gainesville, FL, USA, 32611 (email:[email protected], [email protected]).

a small enough Trojan on the logic and on the side-channelfingerprints of the circuit, can be masked by process variationand noise. This is exacerbated by the ever-increasing scale ofintegration and process-variation in advanced nodes. Recentlyproposed analog and RF Trojans [2] fall into this category. Ananalog Trojan circuit can detect an extremely rare sequentialevent with just a handful of transistors added to the circuit.This hurdles even invasive detection techniques and poses areal threat to the IC supply chain despite a decade of researchin the area.

To guarantee the trustworthiness of a microprocessor, it isdesired for designers to consider the existence of such analogTrojans, and build a corresponding detection framework inthe processor design phase. In this paper, we present a novelon-chip hardware Trojan detection mechanism called R2D2geared towards such analog Trojans. Since such analog Trojansare triggered by high frequency wire-flops in the processor, wepropose an abnormal-toggling detection scheme that can easilybe integrated into the processor with low overhead. We alsodiscuss why it is difficult to remove it from the design. Themain contributions of the paper are listed as follows:

• We develop an on-chip Trojan detection method. Thismethod targets hardware Trojans triggered by a succes-sive toggling events. We present an in-depth securityanalysis of the scheme;

• We design a processor based on the ARMv7-A&R ISA,and insert an analog Trojan (based on the A2 Trojan [2]),into the ARM processor. We explore the architecture ofthe processor and present various novel ways to integratethe Trojan and its payload;

• We provide simulation results, which demonstrate thatthe analog Trojan works on the ARM processor, and theR2D2 method is effective in detecting the analog Trojan;

• We also provide test results based on the taped-outchip. We fabricate a proof-of-concept chip in the SMIC130 nm Mixed-Signal 1P7M process with the hardwareTrojan and the detection mechanism. A testing platformis constructed to test the fabricated SoC. On-board testresults are collected and presented.

The remainder of the paper is organized as follows: SectionII presents comparison to related works. Section III presentsthe R2D2 detection scheme. Section IV provides an overviewof the implemented processor. Section V presents simulationresults and on-board test results, and Section VI concludes thepaper.



II. RELATED WORKS

Hardware Trojans are typically categorized according toa) their triggering method e.g. sequential or combinational,b) their payload e.g. active modification of logic values, orpassive leakage of information through side-channels [3]. Post-fabrication detection mechanisms fall into testing-based [4],[5], or side-channel-based [6], [7]. Various statistical methodshave been used to extract the side-channel traces of a Trojan ina sea of other components. In addition, design time techniquescan also accompany post-fabrication detection such as reduc-ing rare-events in the circuit [8], or inserting on-chip sensorsthat will be measured post-fabrication for Trojan detection [9].

A. Analog Hardware Trojans

Sequentially triggered Trojans can be made extremely dif-ficult to detect through testing patterns. A digital sequentialTrojan typically requires a large FSM to detect a rare sequenceof events, which in turn can reduce the Trojans resiliencyto side-channel detection techniques. Analog switch-capacitorcircuits on the other hand can be used to do signal shapingand detection with a much lower transistor count. The analogTrojan presented in [2] known as A2 uses a simple analogcircuit to detect high frequency toggling.

A2 is a small analog circuit, which can be inserted intoan already placed and routed design. It reads a digital pulsesignal (the trigger input), and triggers the payload when thepulse signal has toggled with a high frequently for a certainperiod of time. The trigger input is connected to a signal thatcan be toggled with high frequency through a special codesnipper running on the processor. The attacker insures thatthe trigger signal has a much lower toggle rate during typicalworkloads. This makes detecting the hardware Trojan difficultthrough testing, not to mention that there exists many lowtoggling frequency bits in modern processors.

VDD

Trigger input

VDD

Trigger

output

Trigger circuit Detector circuit

M0

M1

M2

M3

M4

Cunit Cmain

Figure 1: Transistor schematic of the analog Trojan circuit from [2]

The transistor schematic of the A2 analog Trojan [2] circuitis shown in Figure 1. When the trigger input is low, Cunit

is charged to VDD. When the trigger input switches to high,Cunit shares its charge with Cmain. This will raise the chargeon Cmain by an amount controllable by the size ratio of Cmain

and Cunit. When the trigger input is stationary at either highor low, the charge at Cmain dissipates through M2 and otherstray-paths. Hence, only with sufficiently frequent toggling of

the trigger input, one can raise Cmain’s voltage. This voltageis fed to a detector circuit which is an imbalanced inverterwith a controllable switching threshold. The attacker connectsthe trigger input to a software controllable bit which has alow toggling rate, and uses the trigger output to launch thepayload.

B. Runtime Hardware Trojan Detection Methods

Off-line Trojan detection solutions, such as [10]–[12], aredifficult to expose advanced Trojans like A2 because of itsinsertion stage and software Triggered mechanism. In thissection, we mainly introduce the runtime protection againstmalicious attack.

Application of hardware sensors is able to measure param-eters of circuits. For example, in paper [13], delay amongthe paths between registers are assessed and characterized todefine a reasonable range. All the delays out of the scope arerecognized as malicious behaviors. A shortage of this approachis much extra circuits overheads must be added to insure themonitoring effectiveness and accuracy. Whereas A2 does notdisturb any paths’ delays, this sensor based method does notwork in detecting A2 Trojan.

Power consumption and thermal tracking are common usedfeatures in runtime abnormal behavior check. In [14], throughtracking the temperature profile, the impact of Trojan acti-vation on power consumption in a chip is analyzed. In [15],hardware Trojan activation is detected by comparison of poweruse between Trojan clear and Trojan embedded benchmarksusing machine learning techniques. Another power tracingbased approach is [16], where power monitors are inserted tochip for characterizing the power supply. However, A2 avoidsall the above methods because too few gates are utilized in A2,and it will not cause any fluctuation of either thermal changeor power consumption.

Runtime verification provides a comprehensive protection toICs once the secure properties are well defined. For instance,Verifiable ASICs is proposed by Wahby et.al. [17] to verify thecorrectness of functionality of hardware system. In their paper,runtime (or dynamic) verification is performed by implement-ing an interactive encryption protocol between untrusted ICsand a trusted IC, where the untrusted ICs are called Prover andthe trusted IC is called Verifier. It is the first attempt to com-pute proofs of correct execution through utilizing verifiablecomputation. However, for security purpose, their correctnesschecking method results in too high computational cost andoverhead. Meanwhile, to verify security properties formalizedfrom ICs permitted and prohibited behaviors, a hardwareproperty checker in [18] is utilized to detect hardware andsoftware Trojans, and dynamic checkers in [19] are designed todisclose Processor’s malicious logic. Again, all these checkersare not effective in detecting A2 whose behaviors are hard tobe formalized.

The proposed runtime detection method targets A2-alikeTrojans. Compared with these methods, the proposed detectionmethod is simple and easy to implement. It brings little areaand power overhead.



III. THE R2D2 DETECTION SCHEME

In this paper, we propose an on-chip runtime hardwareTrojan detection method named R2D2 [20]. R2D2 detectionscheme targets A2-alike analog hardware Trojans. It aims todetect high frequency toggling on several signals before theycan activate the hardware Trojan.

A. Detection Method Overview

Detection Mechanism

monitoring timing window

(Tm)

attack threshold (Ath)

interrupt

request

monitoring scope

guarded signal 1

guarded signal 2

guarded signal n

...

Figure 2: Mechanism of the hardware Trojan detection method

Due to the small size of the A2 Trojan, and the fact thatit can be connected to any low toggling signal, we concludethat runtime detection is more feasible. Figure 2 shows themechanism of the proposed runtime hardware Trojan detectionscheme. The principle of this method is to guard a set ofconcerned software controllable registers or memory relatedsignals. A hardware interrupt will be generated if abnormaltoggling events occur in the guarded items. The mechanismcannot be disabled through unprivileged software.

As shown in Figure 2, R2D2 has several parameters thatmust be tuned in order to ensure the effectiveness of thescheme and eliminate false positives. The first parameter isthe size of monitoring timing window denoted by Tm. Duringa monitoring window the detection unit counts the togglingevents on the concerned signal. Throughout this time window,if the toggling frequency increases beyond the Attack thresholdAth, which is the second parameter, the detection circuit willgenerate an interrupt request. The other important parameter isthe monitoring scope which decides the signals to be selectedfor monitoring. These signals must be ones that have a lowtoggling frequency during normal processor workloads. Eachguarded signal can have a different attack threshold value.

Clk

Guarded

Signal

combinational logic

if a = monitoring timing window

b = 0

else

b = 1a

b

c combinational logic

if c = Attack Threshold

detection output = 0

else

detection output = 1

MTW

register

AT

register

Detection

output

clock

counter

toggle

event

counter

Reset

Monitoring

Timing

window

Attack

Threshold

if b=0 c=0

Figure 3: Runtime detection circuit design

The detection circuit is shown in Figure 3. The window size,Tm, and Ath are written into dedicated registers, MonitoringTiming Window register (MTW) and Attack Threshold register

(AT) respectively. By keeping these values as software pro-grammable registers, we can create flexibility and uncertaintyto the defence mechanism and prevent the attacker fromlearning them through IC reverse engineering. We must ensurethat only privileged software can configure these registers. Theclock counter is used to count the clock cycle, and comparewith the value in the MTW register. The clock counter is resetwhen its value reaches the value in the MTW register, and anew monitoring window starts. The toggle event counter isused to count the number of toggle events of the guardedsignal, and compare them with the value in the AT register.This toggle event counter is reset when a new monitoringtiming window starts. In one monitoring window, if the toggleevent counter reaches the value in the AT register, the detectionoutput (the alarm signal) will be activated.

B. Parameter Tuning

Monitoring timing window

Cycle 1 Cycle 2

Trigger time Triggered

Figure 4: The detection method analysis

The first step in securing R2D2 is tuning the scheme’stiming parameters. Per Figure 4, the toggling time it takes fora Trojan to trigger is denoted by Tt, and the average togglingfrequency during this period is denoted by ft. We first assumethat Tt is shorter than twice the size of the monitoring windowsize Tm. The worst case scenario occurs when the triggeringduration scope Tt falls equally into two monitoring windows.In this case, to make sure that the sequential pulse signal canbe detected, the attack threshold Ath should be smaller thanhalf of the number of toggle events Nt required to triggerthe attack. In addition, the value of Ath/Tm should be higherthan the average benign toggling frequency fa of the guardedsignal to avoid false detection. This request is trivial since theguarded signals are supposed to have extremely low togglingrates.

In conclusion, we give the following parameter settingconstrains: {

assume Tt 6 2Tm

fa × Tm ≤ Ath ≤ Nt/2

If the Trojan trigger time Tt is longer than twice of themonitoring window size Tm we just need to make sure thatthe attack threshold is smaller than the number of togglingevents during one of the monitoring windows. The constraintconditions are summarized as below:{

assume Tt > 2Tm

fa × Tm < Ath ≤ Tm × ft



⇒ fa × Tm < Ath ≤ Tt/2× ft = Nt/2

Combining these two situations, we conclude the parametersetting constrains for this detection method as below:{

fa ≤ Ath/Tm ≤ 1Ath ≤ Nt/2

The first condition ensures that the detection scheme elim-inates false positives and the second condition ensures thatattacks will be detected. Once the attack threshold is set, itcan detect hardware Trojans whose trigger time is longer thantwice of the attack threshold. Only hardware Trojans whosetrigger time is shorter than twice of the attack threshold havea chance of evading the detection. In addition, we give thedetection rate of this method below, where n stands for thenumber of toggling events required to activate the hardwareTrojan. The designer can obtain an estimate of n and Tt

by simulating possible analog Trojan designs in the specificTechnology. Note that since these values are programmablethey can also be tuned post-fabrication to give the best results.

detection rate =

0 n ≤ Athn/Ath− 1 Ath 6 n 6 2Ath1 n ≥ 2Ath

In theory an attacker can fine-tune the Trojan to trigger itsooner than the attack threshold. Hence, the closer the designersets the attack threshold to the benign toggling frequencyof the guarded signals the more difficult it becomes for theattacker to evade detection. Note however that this competitionis in favor of the defender due to two reasons. First, thedefender may be able to sustain false alarms. If a false alarmoccurs, execution falls into an interrupt handler. The interrupthandler can perform a quick integrity check, e.g. verify if thesecurity-critical state of the processor such as privilege levelshave been modified or not and return to normal operation ifno such violation is detected. Second, the defender is tuningthe attack threshold through a precise digital counter, whereasthe attacker has to fine-tune the threshold through an analogcircuit which has a higher susceptibility to process variation.

Final

Trigger

Asingle-stage

trigger

circuit A

single-stage

trigger

circuit B

B

OA

OB

single-stage

trigger

circuit A

single-stage

trigger

circuit B

single-stage

trigger

circuit C

A

B

C

OA

OB

OC

Final

Trigger

Final Trigger = OA | OB Final Trigger = (OA & OB) | OC

Figure 5: Multi-stage trigger method from [2]

It is possible that the hardware Trojan is triggered by acombination of multiple single-stage trigger outputs, as shownin Figure 5. Assume the single-stage trigger output is 0 whenactivated. As shown in the figure on the left, the final triggerwill be activated when both trigger circuit A and trigger circuitB are activated. If we replace the OR gate with AND gate, thefinal trigger will be activated when either trigger circuit A or

trigger circuit B is activated. In this case, the trigger conditionis the same with single-stage trigger. But it makes the triggermore flexible, since the final trigger can be activated when oneof many single-stage trigger works. The figure on the rightshows a two level trigger input circuit. The final trigger willbe activate when trigger circuit C and either trigger circuit Aor trigger circuit B is activated.

For OR operation, there are two approaches to activate thefinal trigger. The first method is to toggle wire A and wireB alternatively for required cycles. This requires the Trojandesigner to reduce the toggling frequency requirement of thesingle-stage trigger. The second method is to toggle wire Afor require cycles to active activate trigger circuit A, and thentoggle wire B for required cycles to active activate triggercircuit B. This method requires the retention time of the firstlevel trigger circuit be long enough. Multi-stage trigger methodcan make the trigger more flexible, and can reduce falseactivation. But it is not easy to choose many wires suitableto trigger the attack, and to write software to make all thewires toggle as expected. If the wires are far from each other,it will be difficult to insert the Trojan in a layout. Multi-stage trigger method also means more complex analog circuitdesign. All these features limits the complexity of multi-stagetrigger circuits, and limits the difficulty to detect them.

From the defender’s perspective, we should consider theworst case (the ideal case for the attacker). The monitoredparameter is the toggling frequency of possible victim wires.For R2D2 method, the advantage of multi-stage trigger methodis that it can reduce the required toggling frequency of a victimwire. But anyhow, the required togging frequency is doomedto be higher than common case. For OR operation, assume itcombines N single-stage outputs to trigger the attack. Ideally,it reduce the required toggling rate (ft) by N times (ft/N ).ft/N will be definitely above normal toggling rate. Note thatif ft/N is near or even lower than common case togglingrate, it can be easily detected. It is feasible for us to chooseappropriate MTW and AT values. In the worst case scenario,we will sacrifice false positive rates for higher security level.False positive event only requires the CPU to halt for furtherchecking, but will not affect the processor’s function.

C. Scope Selection

Guarded

Signal

Detection

Circuit

Detection

output

Signal 2

Signal 1

Signal n0

1

0

1

0

1

Detection

Circuit

time multiplexing

Guarded

Signal Detection

output

Gate 1 Gate 2 Gate n…

…

Figure 6: Detection circuit for multiple guarded signals

Selecting the set of guard signals is also a critical part of thedesign. The goal of the defender is to maximize the coverageof low toggling rate signals while minimizing the hardwareoverhead of the detection mechanism.



We first note that since the Trojan detection circuit will besmall, we can easily insert several units in the design withoutincurring significant overhead. In addition, we propose to XORa set of guarded signals together to reduce hardware consump-tion. Figure 6 shows an example circuit. Since the guardedsignals all have low toggling rates when running common pro-grams, the XOR of the signals should also have low togglingrate. If one of the guarded signal toggles frequently, the XORresult toggles as well. But toggling events of other XORedwires will, to some extend, mask the toggling event of thevictim wire. So parameters of the detection circuit need to bemodified accordingly. From the Trojan designer’s perspective,the difference of toggling frequency between the victim wireand other wires will be significant. So the decrease of togglingfrequency of the victim wire will be trivial. We only needto lower the Ath value properly. If the attacker knows theexistence of the detection circuit and the XOR solution, it ispossible for them to mask the high frequent toggling event. Forexample, they can make one XORed wire toggle oppositelywith the victim wire. To realize this goal, they need to inferfrom the layout, the wires are XORed together with the victimwire, and make one wire toggles as expected to mask thevictim wire. This is not easy to realize. If the attacker caninfer from the layout, the signals that are guarded, they cansimply attach the Trojan to signals that are not guarded by thedetector. To thwart this we can use two well known hardwaresecurity measures: 1) Post-fabrication in-house configuration.We can use light-weight configurable MUX-trees [21] androute the detection unit to a large number of potential victimsignals through the configurable tree. The MUXes are thenconfigured post-fabrication to select only a subset of thosesignals unknown to the attacker. 2) Split-manufacturing. Wecan perform the wiring of the detection circuitry in a trustedfoundry. While the substrate devices and the bottom metallayers (including the possible Trojan circuitry) are fabricatedin the untrusted process, the guarded signals are connected ina split-manufacturing style back-end-of-line (BEOL) processunknown to the attacker. The set of guarded signals can bechanged on every batch of chips to create a moving targetdefence against the attacker. The ReRAM-CMOS technologywe use to fabricate our demonstration chip perfectly embracesprogrammable MUX-trees, and BEOL split-manufacturing. Asshown in Figure 6, we can also divide the guarded signalsinto several groups with each group having different detectionparameters Ath and Tm. The XOR gates can time-multiplexto reuse the detection circuit as well. Figure 3 show how theXOR gates can reuse the toggle event counter. In this case, weneed to shrink monitoring window width, and reduce attackthreshold accordingly. We can also add more toggle eventcounters into detection circuit if necessary.

D. Removal Attack Resiliency

Another important security concern is that the attacker mayfind the detection circuit and modify/remove it. We assumethat the attacker has extracted a netlist from the design layout.Then it would be feasible for the attacker to find the detectionunit and the alarm signal and simply disconnect it from

the interrupt unit. We need to verify whether the detectioncircuit works as expected. A low-cost solution to this problemwould be to perform testing-based verification of the detectioncircuitry post-fabrication. This can be done by performingreads and writes to the AT and MTW registers and the scopevariables. Then various toggling benchmark codes can beused on multiple signals inside the detection scope to testwhether the correct interrupt line is triggered at the correctclock cycles. The only way for the attacker to circumventthis stress-testing, is to clone all the software behavior ofthe detection circuitry by modifying the digital circuitry. Thistask would be impossible without significantly disrupting side-channel fingerprints. In essence, such modifications will fallinto the realm of digital Trojans for which there are an arrayof available effective Trojan detection schemes.

IV. DEMONSTRATION DESIGN

We demonstrate the effectiveness of the proposed detectionscheme and the operation of the hardware Trojan itself onan in-house designed ARMv7 compatible processor which isdescribed herein. ARM processors are the most popular pro-cessors in the mobile and embedded system domain. Hence,the security of systems based on ARM architectures is ofcritical concern.

A. The ARM-compatible Processor

We propose a fused microarchitecture [22]–[24] based onthe ARMv7-A&R ISA [25]. ARMv7-A&R was the up to dateARM ISA when we started this project. This ARM processoris named Merlin. Merlin integrates in-order superscalar andVLIW [26]. Normally, Merlin works under dual-issue in-order superscalar mode. It can be switched to six-issue VLIWmode when the task is compute-intensive. It was evaluatedbased on the gem5 simulator [27], and proved to be feasible,before real hardware design [28]. Using michroarchitecturaltechniques [29], Merlin expands the digital signal processingcapabilities of the ARM processor. Merlin supports mosttraditional ARM instructions, but does not support some ISAextensions, such as Thumb, ThumbEE, Jazelle, Floating-point,and Advanced SIMD. We realize 181 ARM instructions intotal, which is enough to run common benchmarks, suchas DhryStone, CoreMark, DSPStone, and EEMBC telecom.There are 7 execution modes defined in ARMv7-A&R ISA,while Merlin works only under user mode.

Branch prediction plays a significant role in improvingthe processor performance, especially for processors withdeep pipeline stages. Merlin has a 10-stage pipeline. Branchprediction happens at the first stage of the pipeline. Until thefirst execution stage (the eighth stage in the pipeline) stage,the correct branch direction can be acquired, and the predicteddirection can be verified to be correct or not. In this design,we propose a combined Bimodal and PAp branch predictionmethod [30]–[33]. This method achieves 94% prediction ac-curacy, with limited hardware budget.

Merlin has 16 KB of on-chip L1 instruction Cache, witha 256-bit wide port, and 32 KB dual-port data memory, witheach port being 64-bits wide. Merlin has six functional units,



ROMITCM

SRAM

system

SRAM

AHB

SPI0

system

controlAHB2APB

SD Host

ControllerDMA

PLL

RRAM

4×128KBMerlin

UART0

UART1

SPI1

TIMER

I2C

GPIO

RTC

JTAG CPU_SELECT

3.3V/4V

outside

CLK

RSTN

AHB BUS 1

AHB BUS 2

APB BUS

Figure 7: The SoC chip diagram

consisting of two arithmetic units, two multiply units, and twoload/store units. An SoC [34] is designed, where Merlin isused as an MCU. The chip diagram is shown in Figure 7. Onthis chip, Merlin is integrated with DMA, ROM, SRAM, four128KB embedded ReRAM, and a variety of peripheral I/O.The Dhrystone performance of Merlin is 1.9 DMIPS/MHz,which is comparable to ARM Cortex-A8 processors.

B. A2-like Analog Trojan in Merlin

When inserting the analog Trojan trigger circuit into theMerlin processor, we should first select a viable trigger input.The trigger input should have low toggling rate in commoncases. It should be controllable through software, so that thetrigger code can make it toggle at high frequency to launchthe attack. We also discuss what can be utilized as the payloadof the trigger in the Merlin processor.

N Z C V QIT

[1:0]J I F T M[4:0]Reserved GE[3:0] E AIT[7:2]

31 30 29 28 27 26 25 24 23 20 19 16 15 10 9 8 7 6 5 4 0

S

Figure 8: ARM CPSR register

1) Select the Trigger Input: In ARMv7-A&R ISA, thereare 16 core registers including R0-R12, SP (Stack Pointer),LR (Link Register), and PC (Program Counter) under usermode. For each core register, it is possible that the registeris frequently used during a time period. So it is not safe toutilize these registers to trigger the attack.

Another software reachable register is CPSR (Current Pro-gram Status Register). The definition of CPSR is shown inFigure 8. APSR (Application Program Status Register) is thesame register as the CPSR in ARMv7-A&R ISA, but theAPSR must be used only to access the N, Z, C, V, Q, andGE[3:0] bits. N, Z, C, and V are condition flags. Q is theoverflow or saturation flag. GE[3:0] are the greater-than orequal flags. In the Merlin processor, we realize all these flagregisters as part of APSR. All the flag registers can be modifieddirectly using the MSR instruction, or be modified indirectlyusing arithmetic or logic instructions.

0.0%

1.0%

2.0%

3.0%

4.0%

5.0%

N Z C V Q GE

Figure 9: Toggling rate of the NZCV, Q, and GE registers whenrunning the MFCC program

Table I: Some special instructions in ARMv7-A&R ISA

Instruction IntroductionPLD, PLDW, PLI Preloading caches

CLREX Clear local exclusive access recordDBG Provide a hint to debug and related systems

DMB, DSB Memory barriers that regulate memory accesses

Figure 9 shows the toggling rate of the NZCV, Q, and GEregisters when running MFCC, which is a speech recognitionprogram. We can see that the toggling rate of N, Z, C registersare all below 5%. V, Q, GE registers does not toggle at all inthis benchmark. So these registers can be utilized as the triggerinput. We also utilize one reserved bit, CPSR[23], as the modeswitch flag in Merlin. We name it CPSR S. The toggle rateof CPSR S is decided by the users. CPSR S always has verylow toggling rate, since it may degrade the performance if theprocessor is to switch between the two modes too frequently.So the CPSR S bit can also be used as the trigger input.

The bits in CPSR that we do not implement in Merlininclude IT[7:0], J, T, E, A, I, F, and M[4:0]. These bits cannotbe modified by MSR instruction directly, but some of thesebits can still be used as the trigger input. J and T compose theinstruction set state register. It indicates whether the processoris working under ARM, Thumb, ThumbEE, or Jazelle mode.The BLX instruction calls a subroutine at a PC-relative address,and changes instruction set from ARM to Thumb, or fromThumb to ARM. Exchange of the instruction set betweenARM and Thumb can make the T bit toggle frequently. Whilethere is little chance that this happens in common cases. So theBLX can be utilized to trigger a Trojan in an ARM processor.IT[7:0] is the IT block state register. This field holds the If-Then execution state bits for the Thumb IT instruction. Itis possible to make one bit in IT[7:0] toggle by exchangingbetween IT mode and normal mode. E is the endiannessmapping register. Normally, endianness is not changed in oneapplication, so the E bit almost does not toggle at all. Butwe can use the SETEND instruction to set and clear this bit,to make E bit toggle frequently. A (Asynchronous abort), I(IRQ), and F (FIQ) are mask bits. These bits are less softwarecontrollable, and it could be dangerous to use these bits totrigger a Trojan attack.

There are also many special instructions which are rarelyused in common programs. Signals related to these instructionsare predicted to have low toggling rates. So these instructionscan also be used to trigger the attack. We list some of the spe-cial instructions in Table I. For example, the PLD instructionsignals the memory system that data memory accesses from aspecified address are likely to happen in the near future. The



memory system can respond by preloading the cache line intothe data cache (pre-fetching). In Merlin, PLD is decoded in theD unit, and then it signals the DMMU. Continuous executionof PLD can make the related signals toggle frequently.

Clock

Bp_en

Figure 10: Branch prediction enable signal toggling rate when run-ning MFCC program

Clock

Bp_en

Figure 11: The branch prediction enable signal toggles more fre-quently if triggered by software

Regarding Merlin, there is another method to trigger theattack. As we mentioned before, Merlin adopts a combinedBimodal and PAp branch prediction method. Merlin fetches256bit instructions each time, including 8 to 16 instructions.This is called an instruction packet. Once branch instructionsare found in the instruction packet, the branch predictionmechanism is enabled. As shown in Figure 10, Bp en standsfor branch prediction enable signal. We can see that theBp en signal rarely toggles when running MFCC program.Whereas, we can make the branch predictor work more fre-quently simply by adding branch instructions into the program.Figure 11 shows that, when running the designed program, theBp en signal toggles more frequently than running the MFCCprogram.

Analog

trigger

circuit

Trigger

input

Peripherals

...

PayloadTrigger

output

COM port

SerDes

PLL

Cache Controller

Bus Controller

DDR PHY

Victim

Figure 12: Possible payloads in Merlin processor

2) Select the Payload: As shown in Figure 12, for the targetSoC, a hardware Trojan can bring many security issues. Forexample, the hardware Trojan may attack memory mappedI/O to invalidate the peripherals, or attack the COM port, orSerDes to cut the communication of the SoC. It can also attackthe PLL to slow down the chip, or attack the cache controller,bus controller, AD/DA converter, DDR PHY, and so on, tomake the chip lose its functionality.

In the hardware implementation, we select the CPSR Jbit as the trigger input. Since Merlin does not support ISAextensions, this bit has no function. We use R0 as the attack

while success==0 do

i ← 0

R0 ← 0

while i<200 do

CPSR_J ← 0

CPSR_J ← 1

i ← i+1

end while

if read(R0) ≠ 0 then

success ← 1

end if

end while

Figure 13: Trojan trigger code

payload. Once the attack is triggered, the value store in R0

will be modified. The trigger code is shown in Figure 13.We generate the trigger input by frequently writing 0 and 1 toCPSR J alternatively. When the Trojan is triggered, it changesthe value stored in R0 from 0 to 1 so that we can observe thechange through a register read.

V. EXPERIMENTAL RESULTS

Considering that the MCU is digital logic, and the hardwareTrojan is analog circuitry, we use Synopsys CustomSim to runsimulation. By declaring the name of the analog top-level celland the analog netlist, CustomSim will simulate the digitallogic via VCS [35], and call the related analog simulator tosimulate the analog logic. In this section, we will give thesimulation result, and introduce the SoC fabrication.

A. Simulation Results

Trigger Time = 9μs

Rentention Time = 15μs

Trigger

Input

Trigger

Output

Cap

Voltage

Trigger

Input

Trigger

Output

Cap

Voltage

Figure 14: A2 Trojan simulation result

Figure 14 shows the simulation result of the A2 analogcircuit. The frequency of the processor is 150MHz. We choosethe CPSR J as the trigger input. The toggling frequency ofthe trigger input signal is 20MHz. The trigger time is 9 µs. Itmeans that the analog Trojan is activated after 180 togglingevents of the trigger input. This result demonstrates that theanalog hardware Trojan works in the ARM processor.

Figure 15 shows the simulation result of the R2D2 detectioncircuit. The detection circuit guards the CPSR J register. Weset the attack threshold as 64, and the monitoring timingwindow is 256 clock cycles. From Figure 15, we can see that



Attack

Detect

Trigger

Input

Trigger

Output

Figure 15: R2D2 detection circuit simulation result

Attack

Detect

Trigger

Input

Trigger

Output

Figure 16: A2 attack simulation without detection

the attack-detected signal generates a low level pulse, afterseveral toggling events of the trigger input. No trigger outputis generated. It means that the Trojan is detected and the attackis prevented. The simulation result when we turn the detectioncircuits off is shown in Figure 16. The attack-detected signalremains 1. Trigger output is generated after several numberof toggling events of the trigger input. The result shows thatthe R2D2 detection method is effective in detecting the analogTrojan.

B. Fabrication

6.5

mm

5μm

9.2mm

31μm

Figure 17: The SoC chip layout

The demonstration SoC is fabricated using the SMIC 130nm Mixed-Signal 1P7M process. The layout of the MCU andthe analog hardware Trojan is shown in Figure 17. Figure 18shows the photo of the SoC silicon die. In the SoC, the MCUis integrated with 16 KB on-chip L1 program Cache, and 32KB dual-port data SRAM. ROM is used to store the bootloader. It also embraces 4Mb embedded ReRAM. As shownin Figure 17, the chip area is 9.2 mm by 6.5 mm. The areaof the analog hardware Trojan is 31 µm by 5 µm. Trojan-to-circuit ratio is 2.6× 10−6.

The detection circuitry is also included in the fabricatedSoC, and it is guarding the CPSR J signal in the MCU. The

MCU

Da

ta S

RA

M

ReRAMarray

ReRAMarray

ReRAMarray

ReRAMarray

Decoder Decoder Decoder Decoder

Driver Driver Driver Driver

L1 Program Cache

ROMPLLSystem SRAM

BT

B T

ab

le

Figure 18: Photo of SoC silicon die

detection circuit is included in the MCU, by automatic placeand route, the gates composing the detection circuits are scat-tered in the layout. The post-layout area of the detection circuitis about 2225 µm2. Detection-to-circuit ratio is 3.7×10−5. Forthe detection circuit, the main area consumption comes fromthe counters. The size of the counters is related to parameterssetting. We set Tm=256, Ath=64, so the clock counter widthis 8, and the toggling event counter width is 6. This includesabout 70 gates. The AT register and MTW register includeabout 12 gates. With these parameters we were able to verifythe operation of the Trojan and detection circuitry successfully.

While we did not implement the ReRAM MUX-trees inthe demonstration chip we were able to verify that there issufficient routing area to route the detection unit to more guardsignals through MUX-trees. Note that the detection scheme isimplemented in digital logic and uses gates similar to othercomponents. This helps better hide the detection circuit froman attacker. Furthermore, the placement tool distributes thedetection units making it more difficult to spot them in thelayout.

C. On-board Evaluation

Figure 19: The PCB board and test environment

1) Test environment: Figure 19 shows the PCB board andthe test environment. The test program is stored into SPI FlashROM. When the board is powered on, the processor will startexecuting the program stored in flash automatically. We cansee printed information on PC screen through UART.

2) Trojan functionality: The trigger output signal of theanalog Trojan circuit is connected to a GPIO, we can capturethe waveform of the Trojan output signal via a oscilloscope,as shown in Figure 20. The Trojan output signal generates a



Figure 20: Analog Trojan circuit on-board test result

21.2 us width low level pulse. This result is consistent withthe simulation result shown in Figure 14 and Figure 16. Indifferent experiments, the width of the low level pulse signalvaries between 20 us and 30 us.

When the analog Trojan is triggered, it will change the valueof R0 from 0X0 to 0X1. We can see the printed value of R0through UART. As shown in Figure 21, after Trojan attack,the value of R0 is changed from 0X0 to 0X1.

Serial port setting

serial port

Baud rate

data width

parity bit

stop bit

flow control

Figure 21: Printed information of the analog Trojan and R2D2detection circuit

3) R2D2 detection functionality: The detection circuit willgenerate a hardware interrupt when possible Trojan is detected.The IRQ number is 15 in this design. As shown in Figure 21,when the detected wire is made toggle frequently by runningthe test program, the detection circuit initiate IRQ 15.

The results demonstrate the feasibility of analog Trojan inthe ARM-compatible processor, and the effectiveness of R2D2detection method.

Table II: Area comparison between Merlin processors with andwithout the R2D2 detection circuit

slice LUTs slice registersMerlin 104330 212243

Merlin with detection 104354 212268increase 0.023% 0.012%

4) Area analysis: In section V-B, we estimate the area ofthe detection circuit in gate level. Based on the parametersof the detection circuit, we estimate that it includes about70 gates, and the post-layout area of the detection circuitis about 2225 µm2. There is no easy way to verify thisestimation, because the circuits are synthesized from thehardware description language, and it is not easy to find outwhich gates compose the detection circuit, considering that thegates are scattered into the layout by automatic placement androuting. To provide a more intuitional illustration of the area

increase, we synthesize two designs on the same FPGA board.The two designs are the Merlin processor with and withoutthe R2D2 detection circuit, separately. The FPGA device weuse is Xilinx XC7Z045FFG676-2. As shown in Table II,compared with the Merlin processor, Merlin processor withR2D2 detection circuit utilizes 0.023% and 0.012% more sliceLUTs and slice registers separately. The area increase is trivial.The area synthesize result shows, quantitatively, how muchhardware resource is used by the detection circuit, but it isnot proportional to the chip area. Many factors affects thearea of the chip layout, and such amount of hardware resourceincrease is negligible.

123.1 123.1

121.9

120.6

119

120

121

122

123

124

Analog Trojan and detection circuit power

evaluation (mW)

Figure 22: Power analysis of the analog Trojan and the R2D2detection circuit

5) Power analysis: Figure 22 shows the power analysis ofthe analog Trojan and the R2D2 detection circuit. To separatethe experiments on the analog Trojan and the R2D2 detectioncircuit, we use one wire as the Trojan trigger input, and useanother wire as the guarded signal of the detection circuit.As a result, the detection circuit does not work when theTrojan is triggered, and the Trojan will not be triggered whenthe guarded signal of the detection circuit toggles. Thus, wecan test the power consumption of the analog Trojan and thedetection circuit separately.

The first two columns (Trojan-disable and Trojan-active)show the Trojan power experiments. Trojan-disable andTrojan-active run the same test program (program 1). Theonly difference is that Trojan enable signal is set as 0 forTrojan-disable test, and Trojan enable signal is set as 1 forTrojan-active test. The detection circuit does not work in thesetwo experiments. These two tests shows the power comparisonwhen the processor works normally and when the analogTrojan is triggered. As Figure 22 shows, power consumptionunder these two occasions are both 123.1 mW. The analogTrojan causes no power increase to the processor.

The last two columns (Detection-disable and Detection-active) show the R2D2 detection circuit power experiments.Detection-disable and Detection-active run the same test pro-gram (program 2). The only difference is that the detectionenable signal is set as 0 for Detection-disable test, and thedetection enable signal is set as 1 for Detection-active test. Pro-gram 1 and program 2 are also similar, except that they makedifferent wires toggle. The trigger input signal of the analogTrojan does not change in these two experiments. As shown in



Figure 22, the power consumption in detection-disable test anddetection-enable test is 121.9 mW and 120.6 mW separately.When the detection circuit is active, the power of the processoris slightly smaller than in normal scenario. That is because thedetection circuit will trigger a interrupt request when suspectTrojan is detected, and it causes the processor to stall for afew cycles.

D. Discussion

R2D2 Trojan detection scheme can be integrated into EDAtools. As shown in Section V-B, the detection circuit is small,and it will bring little overhead to insert many of the detec-tion circuit into the design. EDA tools can collect togglingfrequency data of wires through functional simulation, anddecide the detection scope. Then, DEA tools can add detectioncircuits into the design. It can XOR the target wires nearbyto reduce area consumption. EDA tools can also help to makethe detection circuits more stealthy by scattering the circuitsinto the layout and adding configurable MUX-trees to maskthe detected wires.

VI. CONCLUSION AND FUTURE WORK

In this paper, we implement an analog Trojan in a in-house designed ARM processor. We also propose a runtimeTrojan detection method. The method targets Trojans trig-gered by toggling events, overcoming a significant limitationof existing Trojan detection schemes in detecting A2-alikeTrojans. The chip is also fabricated using SMIC 130 nmMixed-Signal 1P7M process. A PCB board is fabricated. Bothsimulation result and on-board evaluation result prove thatthis method is effective in detecting an analog Trojan insertedin the ARM processor. We intend to continue this researchdirection by exploring topics such as optimal parameter tun-ing, post-fabrication configuration using ReRAMs, and split-manufacturing.

REFERENCES

[1] H. Li, Q. Liu, and J. Zhang, “A survey of hardware trojan threat anddefense,” Integration the VLSI Journal, vol. 55, pp. 426–437, 2016.

[2] K. Yang, M. Hicks, Q. Dong, T. Austin, and D. Sylvester, “A2: Analogmalicious hardware,” in Security & Privacy, 2016, pp. 18–37.

[3] M. Tehranipoor and F. Koushanfar, “A survey of hardware Trojantaxonomy and detection,” Design Test of Computers, IEEE, vol. 27, pp.10–25, 2010.

[4] Y. Jin and Y. Makris, “Hardware Trojan detection using path delayfingerprint,” in IEEE International Workshop on Hardware-OrientedSecurity and Trust (HOST), 2008, pp. 51–57.

[5] S. Narasimhan, D. Du, R. Chakraborty, S. Paul, F. Wolff, C. Papachris-tou, K. Roy, and S. Bhunia, “Hardware Trojan detection by multiple-parameter side-channel analysis,” IEEE Transactions on Computers,vol. 62, no. 11, pp. 2183–2195, 2013.

[6] M. Banga and M. Hsiao, “A novel sustained vector technique for thedetection of hardware Trojans,” in 22nd International Conference onVLSI Design, 2009, pp. 327–332.

[7] S. Saha, R. S. Chakraborty, S. S. Nuthakki, D. Mukhopadhyay et al.,“Improved test pattern generation for hardware trojan detection usinggenetic algorithm and boolean satisfiability,” in International Workshopon Cryptographic Hardware and Embedded Systems. Springer, 2015,pp. 577–596.

[8] H. Salmani, M. Tehranipoor, and J. Plusquellic, “A novel techniquefor improving hardware trojan detection and reducing trojan activationtime,” IEEE Transactions on Very Large Scale Integration (VLSI)Systems, vol. 20, no. 1, pp. 112–125, 2012.

[9] S. Kelly, X. Zhang, M. Tehranipoor, and A. Ferraiuolo, “Detectinghardware trojans using on-chip sensors in an asic design,” Journal ofElectronic Testing, vol. 31, no. 1, pp. 11–26, 2015.

[10] X. Guo, R. G. Dutta, and Y. Jin, “Eliminating the hardware-softwareboundary: A proof-carrying approach for trust evaluation on computersystems,” IEEE Transactions on Information Forensics and Security(TIFS), vol. 12, no. 2, pp. 405–417, 2017.

[11] X. Guo, R. G. Dutta, P. Mishra, and Y. Jin, “Automatic code converterenhanced pch framework for soc trust verification,” IEEE Transactionson Very Large Scale Integration (VLSI) Systems, vol. 25, no. 12, pp.3390–3400, 2017.

[12] A. Waksman, M. Suozzo, and S. Sethumadhavan, “Fanci: identifica-tion of stealthy malicious logic using boolean functional analysis,” inProceedings of the 2013 ACM SIGSAC conference on Computer &communications security. ACM, 2013, pp. 697–708.

[13] J. Li and J. Lach, “At-speed delay characterization for ic authenticationand trojan horse detection,” in Hardware-Oriented Security and Trust,2008. HOST 2008. IEEE International Workshop on. IEEE, 2008, pp.8–14.

[14] D. Forte, C. Bao, and A. Srivastava, “Temperature tracking: An inno-vative run-time approach for hardware trojan detection,” in Computer-Aided Design (ICCAD), 2013 IEEE/ACM International Conference on.IEEE, 2013, pp. 532–539.

[15] T. Iwase, Y. Nozaki, M. Yoshikawa, and T. Kumaki, “Detection tech-nique for hardware trojans using machine learning in frequency domain,”in Consumer Electronics (GCCE), 2015 IEEE 4th Global Conference on.IEEE, 2015, pp. 185–186.

[16] S. Kelly, X. Zhang, M. Tehranipoor, and A. Ferraiuolo, “Detectinghardware trojans using on-chip sensors in an asic design,” Journal ofElectronic Testing, vol. 31, no. 1, pp. 11–26, 2015.

[17] R. S. Wahby, M. Howald, S. Garg, A. Shelat, and M. Walfish, “Verifiableasics,” in Security and Privacy (SP), 2016 IEEE Symposium on. IEEE,2016, pp. 759–778.

[18] X. T. Ngo, J.-L. Danger, S. Guilley, Z. Najm, and O. Emery, “Hardwareproperty checker for run-time hardware trojan detection,” in CircuitTheory and Design (ECCTD), 2015 European Conference on. IEEE,2015, pp. 1–4.

[19] M. Bilzor, T. Huffmire, C. Irvine, and T. Levin, “Evaluating securityrequirements in a general-purpose processor by combining assertioncheckers with code coverage,” in Hardware-Oriented Security and Trust(HOST), 2012 IEEE International Symposium on. IEEE, 2012, pp. 49–54.

[20] Y. Hou, H. He, K. Shamsi, Y. Jin, D. Wu, and H. Wu, “R2D2: Runtimereassurance and detection of A2 trojan,” in Hardware-Oriented Securityand Trust (HOST), 2018 IEEE International Symposium on. IEEE,2018.

[21] X. Tang, G. De Micheli, and P.-E. Gaillardon, “A high-performance fpgaarchitecture using one-level rram-based multiplexers,” IEEE Transac-tions on Emerging Topics in Computing, 2017.

[22] C. Villavieja, J. A. Joao, R. Miftakhutdinov, and Y. N. Patt, “Yoga: Ahybrid dynamic VLIW/OoO processor,” 2014.

[23] C. Fallin, C. Wilkerson, and O. Mutlu, “The heterogeneous blockarchitecture,” in IEEE International Conference on Computer Design,2014, pp. 386–393.

[24] Khubaib, M. A. Suleman, M. Hashemi, W. Chris, and Y. N. Patt,“Morphcore: An energy-efficient microarchitecture for high performanceILP and high throughput TLP,” in Annual IEEE/ACM InternationalSymposium on Microarchitecture, 2012, pp. 305–316.

[25] ARM, “ARM information center,” 2017. [Online]. Available: http://infocenter.arm.com

[26] Z. Shen, H. He, X. Yang, D. Jia, and Y. Sun, “Architecture designof a variable length instruction set VLIW DSP,” Tsinghua Science &Technology, vol. 14, no. 5, pp. 561–569, 2009.

[27] N. Binkert, B. Beckmann, G. Black, A. Saidi, A. Saidi, A. Basu,J. Hestness, D. R. Hower, T. Krishna, and S. Sardashti, “The gem5simulator,” ACM Sigarch Computer Architecture News, vol. 39, no. 2,pp. 1–7, 2011.

[28] Y. Hou, H. He, X. Yang, D. Guo, X. Wang, J. Fu, and K. Qiu, “Fumicro:A fused microarchitecture design integrating in-order superscalar andVLIW,” VLSI Design, 2016.

[29] J. L. Hennessy and D. A. Patterson, Computer architecture: a quantita-tive approach. Elsevier, 2012.

[30] J. K. F. Lee, “Analysis of branch prediction strategies and branch targetbuffer design,” Computer, vol. 17, no. 1, pp. 6–22, 1984.

[31] J. E. Smith, “A study of branch prediction strategies,” Proceedings ofthe 8th annual symposium on Computer Architecture, vol. 29, no. 6, pp.135–148, 1981.



[32] J. Hoogerbrugge, “Dynamic branch prediction for a vliw processor,”in International Conference on Parallel Architectures & CompilationTechniques, 2000, pp. 207–214.

[33] G. Palermo, M. Sam, C. Silvan, V. Zaccari, and R. Zafalo, “Branchprediction techniques for low-power vliw processors,” in ACM GreatLakes Symposium on Vlsi 2003, Washington, Dc, Usa, April, 2003, pp.225–228.

[34] S. Furber, “ARM system-on-chip architecture,” Network IEEE, vol. 14,no. 6, p. 4, 2000.

[35] G. Nunn, F. Delguste, A. Khan, A. Verma, and B. Geden, “Whitepaper using digital verification techniques on mixed-signal socs withcustomsim and vcs,” Synopsys, Tech. Rep., 2011.

Yumin Hou received the B.S. degree in Micro-electronics from the School of Microelectronics andSolid-State Electronics, University of Electronic Sci-ence and Technology of China, Chengdu, China, in2012. She is currently a Ph.D. candidate in Electron-ics Science and Technology at Tsinghua University,Beijing, China, under the supervision of Dr. HuHe. Her main research interests include computerarchitecture design, Processing-in-Memory architec-ture and programming model design, and processorsecurity.

Hu He received his B.S. and Ph.D. degree from theDepartment of Automation and the Institute of Mi-croelectronics, Tsinghua University respectively. Heis currently an associate professor with the Instituteof Microelectronics, Tsinghua University, Beijing,China. His research interests include DSP archi-tecture, compiler, processor hardware security, andProcessing-in-Memory architecture. His group hasdeveloped several generation DSPs in last decade.One VLIW DSP developed for wireless communi-cation and finally used in video surveillance system

for cryptography processing was volume produced. He is also interested inspiking neural network learning method, neuromorphic computing, and neuralnetwork hardware accelerator.

Kaveh Shamsi received the B.S. degree in Elec-trical Engineering from the Sharif University ofTechnology, Tehran, Iran, in 2014, the M.S. degreein Computer Engineering from the University ofCentral Florida, Orlando, US in 2017. He is currentlypursuing a Ph.D. degree in Electrical and ComputerEngineering at the University of Florida Florida,Gainesville, US under the supervision of Dr. YierJin. His research focuses on analog and digital circuitdesign, formal methods, and algorithms in hardwaresecurity. He is the recipient of the HOST’17 best

paper award and the GLSVLSI’18 best paper candidate.

Yier Jin is currently an associate professor in theECE Department at the University of Florida. Hereceived his PhD degree in Electrical Engineeringin 2012 from Yale University after he got his B.S.and M.S. degrees in Electrical Engineering fromZhejiang University, China, in 2005 and 2007, re-spectively.

His research focuses on the areas of trusted em-bedded systems, trusted hardware intellectual prop-erty (IP) cores and hardware-software co-protectionon computer systems. He proposed various ap-

proaches in the area of hardware security, including the hardware Trojandetection methodology relying on local side-channel information, the post-deployment hardware trust assessment framework, and the proof-carryinghardware IP protection scheme. He is also interested in the security analysison Internet of Things (IoT) and wearable devices with particular emphasis oninformation integrity and privacy protection in the IoT era. He is awarded theDoE Early CAREER Award in 2016 and is the best paper award recipient ofDAC’15, ASP-DAC’16, HOST’17, ACM TODAES’18, and GLSVLSI’18.

Dong Wu received the B.S. degree in electronicengineering from Xi’an Jiaotong University, Xi’an,China, in 2001, and Ph.D. degree in microelectronicsfrom Tsinghua University, Beijing, China, in 2006.He is an associate professor in Tsinghua University,and his research focus is circuit design for sensorsand memories.

Huaqiang Wu is presently the deputy director of theInstitute of Microelectronics, Tsinghua University,Beijing, China. Dr. Wu received his Ph.D. degreein electrical engineering from Cornell University,Ithaca, NY, in 2005. Prior to that, he graduated fromTsinghua University, Beijing, China, in 2000 withdouble B.S. degrees in material science engineeringand enterprise management. From 2006 to 2008, hewas a senior engineer in Spansion LLC, Sunnyvale,CA. He joined the Institute of Microelectronics,Tsinghua University in 2009. His research interests

include emerging memory and neuromorphic computing technologies. Dr. Wuhas published more than 100 technical papers and owns more than 60 patents.Dr. Wu is also served as the director of Micro/Nano Fabrication Center anddeputy director of Beijing Innovation Center for Future Chips.

on-chip analog trojan detection framework for ...jin.ece.ufl.edu/papers/tcad18.pdf · a. analog...

Documents