IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 41, NO.
11, NOVEMBER 2022 3661
BLAST: Belling the Black-Hat High-Level
Synthesis Tool
Mohammed Abderehman , Rupak Gupta, Rakesh Reddy Theegala, and Chandan Karfa, Senior Member, IEEE
Abstract—A hardware Trojan (HT) is a malicious modifica-
tion of the design done by a rogue employee or a malicious
foundry to leak secret information, create a backdoor for attack-
ers, alter functionality, degrade performance and even halt the
system. In Black-hat high-level synthesis (HLS) (Pilato et al.,
2019), the authors have introduced a possibility of HTs inser-
tion in the register transfer level (RTL) design by the HLS tool
itself. Specifically, degradation attack (DA), battery exhaustion
(BE) attack, and downgrade attack (DG) have been proposed in
that work. In this study, we show how all three HTs inserted by
Pilato et al. (2019) can be detected using a C-to-RTL equivalence
checking framework. We have assumed that both the input C
code and the Trojan-infected RTL code are available for our anal-
ysis. Specifically, our framework extracts an RTL-level finite-state
machine with datapaths (RTL-FSMDs) from the HLS-generated
RTL. During finite-state machine with datapath (FSMD) con-
struction, a BE attack can be identified. Our proposed method
then compares the FSMD of the input C code with the RTL-
FSMD to identify the DA and the DG. The experimental results
confirm the detection of HTs of the black-hat HLS tool.
Index Terms—Finite-state machine with datapath (FSMD),
hardware Trojan (HT), high-level synthesis (HLS), HLS opti-
mizations, register transfer level (RTL), rewriting method.
I. I NTRODUCTION
HE COMPLEXITY of modern day integrated circuits
T (ICs) is growing exponentially [2]. To keep pace with this
complexity and to reduce design time, the use of high-level
synthesis (HLS) [3] tools are rapidly increasing. About 14 out
of the top 20 semiconductor companies are using HLS tools
for IC development [4]. The HLS tool converts the high-level
C/C++ input specification into equivalent register transfer
level (RTL) design. The substeps of the HLS process are:
1) preprocessing which applies various compiler optimization;
2) the scheduling phase that assigns each operation to a
time step; 3) allocation and binding which identifies mini-
mum functional units (FUs) and registers for the operations
and the variables, respectively, of the C specification based
on schedule; and 4) datapath and controller generation which
creates the datapath interconnections and a controller finite
state machine (FSM). The RTL consists of a datapath and a
Manuscript received 5 August 2022; accepted 5 August 2022. Date of
current version 24 October 2022. The work of Chandan Karfa was sup-
ported in part by the Department of Science and Technology (DST), India,
under Grant CRG/2019/001300, and in part by the Qualcomm Faculty
Award 2021. This article was presented at the International Conference on
Hardware/Software Codesign and System Synthesis (CODES+ISSS) 2022
and appeared as part of the ESWEEK-TCAD special issue. This article was
recommended by Associate Editor A. K. Coskun (Corresponding author:
Mohammed Abderehman.)
The authors are with the Department of Computer Science and Engineering,
Indian Institute of Technology Guwahati, Guwahati 781039, India
(e-mail: ma.adem@iitg.ac.in; rgupta@iitg.ac.in; rakes170101071@iitg.ac.in;
ckarfa@iitg.ac.in).
Digital Object Identifier 10.1109/TCAD.2022.3200513
1937-4151 
c 2022 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
controller FSM. Higher abstraction level, shorter design cycle,
easy design space exploration, 10× less coding at a higher
level, and shorter verification time make HLS an attractive
starting point for the IC developers [5].
Hardware Trojans (HT) [6] are malicious design modifica-
tions by an adversary to either change functionality, degrade
performance, leak information, or denial of service. The HT
has two main parts: 1) a trigger: a circuit (signal) that acti-
vates the Trojan and 2) a payload: a circuit that performs
the malicious function activated by the trigger signal. Most
of the HTs are activated by a rare condition. The circuit per-
forms correctly in normal scenarios. Therefore, HTs are very
hard to detect during the presilicon validation phase. Once
the HT is activated, the circuit will start malfunctioning. The
HTs may also be inserted in any phase of the design cycle
by an untrusted synthesis tool [1], [7]. The impact of HTs
includes economic damage, planned to obsolesce or cyber-
attack on national assets [8]. Therefore, the detection of HTs
is an important task for securing the design. This is an active
domain of research in this decade [9], [10], [11], [12].
The commercial electronic design automation (EDA) com-
panies sold proprietary HLS CAD tools with a set of IPs as
their component library. It may be the case that the licensed
software is altered by a rogue employee. As result, the HLS
tool will generate Trojan-infected hardware which may not
perform as expected after a certain time (i.e., once the Trojan
gets activated). The employee may do this to create significant
economic damage for the company or to give attackers access
to the secret key of a cryptography hardware or to create a
bad name for the company. Since the HT primarily reuses the
actual datapath components, it will be hard to detect them by
the testing phase.
In a recent study [1], [7], it is shown that HT can actually
be inserted by the HLS tool itself. The authors have shown
that it is easy to insert HTs by the HLS tool compared to
other EDA tool like logic synthesis and physical synthesis
tool. Specifically, the Black-Hat HLS tool [1] inserts three
types of HTs: 1) battery exhaustion attack (BE) which may
increase power consumption; 2) degradation attack (DA) to
degrade the performance of the IPs; and 3) downgrade attack
(DG) to reduce the security level of the design. Since HLS
process transforms an un-timed C/C++ code into a timed RTL
code, applies various optimization in each of its substep, it is
a difficult task for the formal verification tools to find the
correlation between the initial specification and the generated
RTL by HLS tool [13]. Therefore, simulation is the primary
way to verify the correctness of the HLS result. Since it does
not provide complete coverage, HT inserted during HLS may
likely to be undetected.
The objective of this work is to develop a formal HLS
Trojan detection framework. Since an HLS tool user generates
RTL from an initial C specification, we assume that a detec-
tion framework has access to both the initial C code and the
 3662 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 41, NO. 11, NOVEMBER 2022
corresponding RTL code. However, it does not have access
to any intermediate synthesis information like scheduling of
operations, variable to register mapping information, etc. of
the HLS tool. The question is “can we detect the HLS Trojan
by comparing the generated RTL with the initial C specifica-
tion?” It may be noted that our objective is not proving the
equivalence between the C and the RTL, rather, we try to find
the difference between these two behaviors. This behavioral
difference may lead to the detection of HLS HTs.
Our HT detection framework is developed by utilizing two
of our previous works FastSim [14] and DEEQ [15]. In [14], a
way to extract a high-level behavior from the HLS-generated
RTLs is shown. In [15], that high-level behavior of the RTL
is used to prove the equivalence between the C and RTL.
For completeness of this article, we discuss the ideas of [14]
and [15] briefly in this article. However, FastSim or DEEQ
cannot detect HLS inserted HTs. In this work, we developed
an HT detection framework by utilizing the power of them.
Specifically, we are looking for any inconsistency or difference
during the extraction of a high-level behavior from the RTL
in [14] or during equivalence checking in [15]. Once such
difference or inconsistency is identified, we further analyzed
them to detect the HTs. Specifically, the contributions of this
article are as follows.
1) A detection mechanism called BLAST for HLS tool
inserted HTs [1] is presented here.
2) The BLAST utilizes method that extracts a high-level
behavior from RTL and a C-to-RTL equivalence check-
ing method for HT detection.
3) We have shown that all HLS Trojans presented [1] can
be identified by BLAST.
4) A prototype of BLAST is implemented. The experimen-
tal results show the usefulness of the proposed method.
This is the first attempt to detect the HLS inserted HTs.
The remainder of this article is organized as follows. In
Section II, related works are discussed. Background and
overview of BLAST are presented in Section III. Detection of
HTs are presented in Sections IV–VI. The experimental results
are presented in Section VII. The performance of BLAST
for various HLS optimizations is discussed in Section VIII.
Section IX concludes this article.
II. R ELATED W ORKS
A. Hardware Trojan Detection
The HT detection mechanisms depend on the deployment
phase (like, specification, RTL, layout, and fabrication) and
the required inputs (like, golden chips, etc.) A survey of sev-
eral techniques for detecting HT at different design flow has
been presented in [16]. In [17], optical inspection-based HT
detection technique is presented. In this method, the layout of
the circuit under test is compared with a picture of the man-
ufactured circuit under test, obtained by removing the layers
one by one. This method requires sophisticated and highly
accurate techniques to obtain and analyze the die photo of the
chip under test. However, the process is expensive and time
consuming to apply it. Jha and Jha [18] proposed a randomiza-
tion to compare, in probability, the functionality of the original
design and the final circuit. Salmani et al. [19] presented a
technique to increase the probability of generating a transi-
tion in a Trojan and analyze its activation time. In both cases,
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
however, it is not guaranteed to find the test vectors capa-
ble of triggering Trojans and, therefore, detection using this
technique is not guaranteed.
In [20], side channel-based HT detection mechanism has
been presented. In this method, principle component analysis
(PCA) is used as side-channel fingerprint of the circuit to com-
pare it with the golden model. However, the characteristics of
the physical design can be modified by other factors and not
only by HT. As a result, HT detection may not be effective
and time consuming. Liu et al. [21] have replaced the require-
ment of the golden model by using golden parametric signature
obtained by trusted simulation model, parameters from die and
applying advanced statistical modeling techniques. However,
the requirement of precise model of the process makes the
technique difficult. In [22], run time detection technique has
been presented. Both hardware and software have been used
to detect HT. Additional circuit (logic) is added in order to
support a security monitoring at run time. But, this tech-
nique is expensive in terms of circuit area. Hicks et al. [9]
presented an HT detection method at RTL level. The HT detec-
tion problem is formulated as an unused circuit identification
(UCI) problem. However, how to define unused circuit is not
easy and is not quite clear. Therefore, most of these approaches
compared golden model with design circuit to detect HT. To
the best of our knowledge, there is no techniques that can
detect high level synthesis (HLS) HTs [1].
B. Verification of HLS
Formal verification of HLS is still evolving. Most
of the existing techniques proposed phase-wise verifica-
tion of HLS [23]. These methods rely on intermediate
synthesis information from the HLS tool. Several path-
based equivalence checking methods have been proposed
for verification of compiler optimization and scheduling
tasks [24], [25], [26], [27]. In these methods, the input C
specification and the scheduled behavior are modeled by
an FSM with datapaths (FSMDs). In general, path-based
approaches decompose each FSMD into a set of paths and
the equivalence is established by showing path-level equiva-
lence between two FSMDs. There are few works that target
verification of register allocation [28] and the datapath and
the controller generation phase [29] as well. However, these
methods are not applicable for end-to-end verification of
HLS. A recent work [15] proposes C to RTL equivalence
checking for HLS. In the presence of an HT in the RTL,
this method may not show the equivalence or may result
in false positive. Therefore, the method needs to be tuned
and further analysis is needed to detect HLS HT. Therefore,
these approaches are not directly applicable for HLS HT
detection.
III. BACKGROUND AND OVERVIEW OF BLAST
In this work, we model C and RTL as FSMDs. The FSMDs
and the equivalence theory are discussed briefly here.
A. FSMDs and Their Equivalence
An FSMD is an inherently deterministic model that can rep-
resent any hardware circuit [30]. An FSMD M is defined as a
7-tuple Q, q0 , I, O, V, f , h, where Q is the finite set of states,
q0 ∈ Q is the reset (initial) state, I is the finite set of input
variables, O is the finite set of output variables, V is the finite
 ABDEREHMAN et al.: BLAST: BELLING THE BLACK-HAT HLS TOOL
set of storage variables, f : Q × 2S → Q is the state transition
function, h : Q × 2S → U is the update function. Here, S
represents the set of relations over arithmetic expressions and
Boolean literals and U represent a set of storage and output
assignments.
A trace of an FSMD is a finite walk from the reset state
q0 to itself, and q0 should not occur in between. The con-
dition of execution cτ of a trace τ is a logical expression
over I, which must be satisfied by the initial data state in
order to traverse the path τ . The data transformation sτ of a
trace τ over O is an ordered tuple ej  of algebraic expres-
sions over I such that the expression ej represents the value
of the output oj after execution of the trace in terms input
variables. Computation of the condition of execution and data
transformation can be obtained by forward substitution. The
forward-substitution method of finding data transformations
is based on symbolic execution [31]. A path p from qi to qj ,
where qi , qj ∈ Q, is a finite transition sequence of states where
all the intermediate states are distinct.
Let the input C behavior be represented by the FSMD
M0 = Q0 , q0,0 , I, V0 , O, f0 , h0  and the RTL be represented
by the FSMD M1 = Q1 , q1,0 , I, V1 , O, f1 , h1 . It may be noted
that the inputs and outputs of both the behaviors are identi-
cal. V0 consists of the variables in the input C program. V1
consists of registers of the RTL behavior. The state transition
function may differ since the control structure may be altered
due to application of compiler transformations or by schedul-
ing. The equivalence of M0 and M1 means that for all possible
inputs, the execution traces of M0 and M1 produce the same
outputs. So, a trace, which represents one possible execution
of an FSMD, takes one assignment of inputs and produces the
outputs. The equivalence of traces can be defined as follows.
Definition 1 (Equivalence of Traces): A trace τ0 of an
FSMD M0 is equivalent to a trace τ1 of another FSMD M1 ,
denoted as τ0  τ1 , if cτ0 ≡ cτ1 and sτ0 ≡ sτ1 , where cτ0 and
cτ1 represent the conditions of execution of τ0 and τ1 , respec-
tively, and sτ0 and sτ1 represent the data transformations of τ0
and τ1 , respectively.
The following two definitions capture the notion of equiv-
alence of FSMDs.
Definition 2 (Containment of FSMDs): An FSMD M0 is
said to be contained in an FSMD M1 , symbolically M0 M1 ,
if for any trace τ0 of M0 , there exists a trace τ1 of M1 such
that τ0  τ1 .
Definition 3 (Equivalence of FSMDs): Two FSMDs M0 and
M1 are said to be computationally equivalent, i.e., M0  M1 ,
if M0 M1 and M1 M0 .
B. BLAST: HLS Trojan Detection Framework
The semantic gap between the C and RTL is the primary
challenge in correlating the C and corresponding RTL gen-
erated by an HLS tool. To tackle this, we first abstract out a
high-level behavior, called RTL level finite-state machine with
datapath (RTL-FSMD), from the RTL using the idea of [14].
The input C code is modeled as C-FSMD. Next, the equiva-
lence checking between input C-FSMD code and RTL-FSMD
is carried out.
We can detect all three HTs inserted by the Black-hat
HLS tool [1] during this process. The overall flow of our
HT detection framework BLAST is given in Fig. 1. During
RTL-FSMD extraction from the RTL, any spurious form of
operation will be identified. With further analysis, the BE
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
3663
Fig. 1. Overall flow of our HT detection framework.
attack can be detected. The DA and the DG will be detected
using equivalence checking. The detection mechanisms are
discussed in detail in the following sections.
IV. D ETECTION OF BATTERY E XHAUSTION ATTACK
Hardware circuits (especially small devices created with
IPs) require a battery power source. Managing energy utiliza-
tion is a key design principle in a circuit design. BE attacks
can drain out power by including extra (useless) or idle FUs
that use a considerable amount of power from the source. As a
result, extra power will be consumed by the useless FU when
it is switched on and battery lifetime is shortening with no
impact on the functionality.
A. Attack Model
In a BE attack in [1], the idle FUs will be used to drain out
the power when the Trojan is activated. The number of FUs
required for one type of operation (e.g., multiplier) is deter-
mined by the maximum number of that operation scheduled to
execute in parallel in a control state. In a control state where
the number of operations scheduled is less than the number
of FUs present in the datapath, some of the FUs will remain
idle in that state. These idle FUs are reused to execute some
fake operations in a BE attack. The actual inputs of the idle
FU are bit-flipped and then multiplexed with the actual inputs
for the FU. This multiplexer is controlled by the Trojan trig-
ger. The results of such fake operations will not be stored
in the destination register. This can be done by disabling the
write enable signal of the destination register. If no idle FU
is available in any control state, the tool may insert an addi-
tional state and implement the attack on that state. The idea
behind this attack is to trigger the combinational functionality
and enhance dynamic power consumption.
Example 1: Let us consider the example given in Fig. 2.
The expected datapath is shown in Fig. 2(a). The inputs in1
and in2 to the multiplier are from many time multiplexed regis-
ters. The details are not important in our context. We consider
only the relevant part of the datapath to explain the effect of
the BE attack. The datapath is modified as shown in Fig. 2(b)
to introduce the attack. Specifically, the output of the multi-
plexer is negated (i.e., bit-flipped) and is multiplexed with the
actual input of the multiplier. The bit-flipped data is stored
 3664 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 41, NO. 11, NOVEMBER 2022

Algorithm 1: RTL-FSMD_Extraction
Input: RTL
Result: RTL-FSMD
/* RTL consists of a datapath D and a
controller FSM F */
1 foreach state S in the controller FSM F do
2 Find the active micro-operations MS for the control
(a) signal assignments in S;
(b) 3 RS = ; /* Set of RT-operations in S
*/
4 foreach micro-opn of the form μ:r ← rin in MS do
/* Rewrite method */
5 do
(c) (d) 6 w = Find the left-most wire signal in the
RHS exp μe of μ;
Fig. 2. Example to illustrate the effect of BE attack. 7 Find a micro-opn of the form w ← ew in MS ;
8 Replace w with (ew ) in the μe ;
9 while (all signals in RHS exp μe of μ are either
in the register to avoid the combinational loop. These two Input, Reg or Constant);
additional multiplexers and the registers are controlled by the 10 R S = RS ∪ {μ};
Trojan trigger tj. 11 end foreach
The BE attack will be detected during the RTL-FSMD 12 Replace the control signal assignments in S of F with
extraction from the Verilog RTL. The HLS generated RTL RS ;
13 end foreach
has a separate datapath and controller FSM. So, in the FSMD
14 Return F; /* FSM F is converted to FSMD F
extraction phase as explained in [14], the datapath is analyzed
at this point */
for the control signal assignment of each state and the RTL
operations executed in that particular state are identified. This
way the controller FSM and datapath can be converted into an
equivalent FSMD which is nothing but a high-level behavior.
The overall idea of RTL-FSMD extraction process is explained
in the next section and how BE attack will be detected during
that phase in the subsequent section.

B. RTL-FSMD Extraction
In the datapath, signal flow is controlled by the control sig-
nals. For each datapath module, input to output assignments (a)
is termed as micro-operations. For example, for a multiplexer
out = MUX(in1, in2, sel), there are two micro-operations
possible, i.e., out ← in1 and out ← in2 and the associ-
ated control signal assignment are sel = 0 and sel = 1,
respectively. Given a control signal assignment in a control
state, we have a set of active micro-operations in each transi-
tion of the controller FSM. All the assignment operations are
active in all control steps. The RTL operations in each state
are then obtained by application of the rewriting method of (b) (c)
the work [14]. Starting from a micro-operations of the form
Fig. 3. (a) Controller FSM. (b) Datapath. (c) RTL-FSMD.
r ⇐ rin , the rewriting method identifies the spatial sequence
of data flow needed for an RT operation in reverse order. The
method consists in rewriting terms one after another in the
right-hand-side expression using the active micro-operations. Example 2: Let us consider the datapath and controller
The method stops when all the terms in the RHS are either FSM shown in Fig. 3. All the control signal names start with
registers, inputs, or constants. The rewriting takes place from CS. Let the order of the control signals be CSr1, CSr2, CSr3,
left to right in a breadth-first manner. CSr4, CSm1, CSm2, CSm3, CSm4, CSf1, CSf2, CSf3. Let
The above process will identify the RTL operation(s) exe- us consider the control assertion A = 0, 1, 0, 0, 1, 0, 0, 1, 1,
cuted in a state of the controller FSM. The same process can 0, 1 of the transition q2 → q3 . For this control signal assign-
be applied for each state of the controller FSM to extract the ment, the activated micro-operations are:{r1out ⇐ r1, r2out
RTL-FSMD from the RTL. The extraction process is given in ⇐ r2, r3out ⇐ r3, r4out ⇐ r4, m1out ⇐ r3out, m2out ⇐
Algorithm 1. Lines 5–9 in the algorithm represent the rewriting r1out, m3out ⇐ r3out, m4out ⇐ r4out, f1out ⇐ m1out +
process. In this method, we use a Mealy Model representation m2out, f2out ⇐ m3out - m4out, f3out ⇐ f1out * f2out, r2 ⇐
in which the operations are associated with the state transition. f3out}. Out of them, r2 ⇐ f 3out is the micro-operation with
Based on the transition condition, the operation performed is register r2 at LHS. The sequence of the rewriting process to
decided. The process is explained with an example below. accomplish the corresponding RT-operation are as follows:

Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
 ABDEREHMAN et al.: BLAST: BELLING THE BLACK-HAT HLS TOOL
r2 ← f3out
r2 ← f1out * f2out [since f3out⇐ f1out * f2out]
r2 ← (m1out + m2out) * (m3out − m4out) [since f1out←
m1out + m2out and f2out⇐ (m3out − m4out)]
r2 ← (r3out + r1out) * (m3out − m4out) [since m1out⇐
r3out and m2out⇐ r1out ]
r2 ← (r3out + r1out) * (r3out − r4out) [since m3out⇐ r3out
and m4out⇐ r4out]
r2 ←(r3 + r1) * (r3out − r4out) [since r3out⇐ r3, r1out⇐r1]
r2 ← (r3 + r1) * (r3 − r4) [since r3out⇐ r3, r4out⇐ r4].
Since r1, r3, and r4 are registers in the RHS, the rewriting
process stops. So, the RT-operation r2 ← (r3 + r1) * (r3 − r4)
is executed by the given control assignment in the transition
q2 → q3 . The RT-operation for other state transitions of the
FSM can be found in a similar manner. The obtained RTL-
FSMD behavior is given in Fig. 3(c).
C. Detection
Our idea of detection is to identify the Trojan pattern shown
in Fig. 2(b) in the datapath during FSMD extraction. The
trigger to identify such a pattern is when an RTL opera-
tion of the form R ← ¬R (bit-flipped) is found in a state
during rewriting method. For each state si , there are some
active micro-operations. The rewriting method takes a micro-
operation in which a register Ri presents in LHS and keeps
rewriting the RHS terms one by one until the RHS expression
consists only inputs, registers, or constants. If the rewriting
method starts with a micro-operation Ri ← w (where w is a
wire signal) and stops with an RTL operation Ri ← ¬Ri , then
we store the instance of the register in the set Rbf (set of bit-
flipped register). Here, the RHS consists only the LHS register
in negation form. We then perform the following analysis to
identify the attack.
We shall collect all the bit-flipped registers in a set Rbf in
each control state. We shall also collect all the idle FUs (Fidle )
in each control state. Let us assume that the FU fi is idle in
control state sn . An FU is idle in a control state if it is not
used by any of the RTL operations in that state. The same can
be identified by some additional book-keeping in Algorithm 1.
Since all the control signals have some value in each control
state, data from some registers are coming to the inputs of an
idle FU as well. We now apply the rewriting method from the
output of the idle FU. This will identify the operation starting
from the idle FU output (and not from a destination register).
This operation for fi is called input pattern to fi . If the input
pattern of fi contains any register from the set Rbf , we shall
report a possible BE attack in the state sn with all relevant
details to the user. The overall idea is that if some register’s
value is bit-flipped whenever the trigger signal is on and that
register’s value is used in some FU and the output of the FU is
not utilized then that is the instance of BE attack. The overall
detection mechanism is presented as Algorithm 2.
Example 3: Let us now consider the example given in
Fig. 2. Let assume that the multiplier in Fig. 2(a) is idle in
state s1. Since the multiplier is idle in s1, the register r1 will
not be updated in this state. The multiplier output can be visu-
alized as fOut ← in1 × in2 in normal mode as shown in
Fig. 2(c). This is the correct version of the controller for this
state transition. However, the controller FSM behavior will be
affected by the BE attack as shown in Fig. 2(d). In this case,
there will be two transitions controlled by the Trojan trigger tj
from the state s1 in the HT affected design. In a normal mode
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
3665
Algorithm 2: Detect_BE_Attack (RTL, sn )
Result: An instance of the battery exhaustion attack in
the state sn .
1 Collect all bit-flipped registers in the state sn in Rbf from
RSn (Ref Algorithm 1);
2 Collect all idle FUs in the state sn in Fidle .
3 for each Register ri in Rbf do
4 for fi ∈ Fidle do
5 Apply the rewrite method from the output of the
idle FU fi .
6 if the input pattern of fi contains any register
from Rbf then
7 Report “A possible instance of battery
exhaustion attack” with relevant detail.
8 end if
9 end for
10 end for
11 Report “No battery exhaustion attack is found in the state
sn .”
when the HT is disabled, i.e., tj is False, no spurious operation
will be executed. However, when the Trojan is triggered, the
spurious operations as shown in the transition with condition
tj will be executed.
During FSMD construction, Algorithm 2 will identify the
operations r4 = ¬r4 and r5 = ¬r5 in line 1 and stores r4
and r5 in Rbf . Since the multiplier is idle in this state, the
rewriting method will identify the input pattern r4 × r5 for
the multiplier. Since r4 and r5 occur in the input pattern of
the multiplier, Algorithm 2 will report a possible BE attack. In
addition, it will also report the involved multiplexers, registers,
and the FU for further debugging.
V. D ETECTION OF D EGRADATION ATTACK
The IPs are reused in different applications of system design
to reduce design costs. They are excellent candidates for hard-
ware accelerator design. Many circuit design companies use
HLS tools to create reusable IPs at high-level specifications.
Therefore, an attacker is more interested in potential mod-
ification of the IPs during the design process. In the DA,
the attacker inserts empty states in the controller FSM. As
a result, the performance of the IPs will degrade when the
Trojan trigger is activated.
A. Attack Model
The DA inserts a few empty states (i.e., bubble) in the con-
troller FSM. These bubbles create a divergence in control flow
(i.e., an alternative path) from a specific state si before com-
ing back to the next state si . The transitions are controlled
by the trigger signal of the Trojan. This alternative trace just
consumes some extra clock cycles before coming back to the
original behavior. The circuit will perform properly in a normal
scenario. The Trojan can be activated only after a predefined
amount of time or in the case of a specific input sequence.
When a Trojan is activated, the alternative trace is executed
and it will slow down (i.e., degrade) the actual computation.
Example 4: Let us consider the FIR behavior in Fig. 4.
The behavior is simplified by removing a few loops related
to the memory read and wait for the start signal for simplifi-
cation. The corresponding C-FSMD obtained from the input C
 3666 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 41, NO. 11, NOVEMBER 2022
Fig. 4. C code for FIR filter.
(a) (b)
Fig. 5. Example to illustrate the effect of DA. (a) C-FSMD. (b) RTL-FSMD
after HT insertion.
is shown in Fig. 5(a). The RTL-FSMD obtained from the RTL
is shown in Fig. 5(b). The HLS tool inserts a bubble state t7
as shown in Fig. 5(b). The DA creates a divergence of control
flow from the state t4. In the normal scenario, the transition
t4 −
→ t5 will be executed. So, there will be no degradation. The
!tj
execution will follow the bubble state (t4 −→ t7 → t5) when the
tj
Trojan trigger tj is True. As a result, for every iteration, there
will be one cycle of degradation. The bubble is inserted inside
the loop which iterates ntaps time. Therefore, total degradation
will be ntaps cycles.
The DA will be detected during equivalence checking
between C-FSMD and RTL-FSMD. The DA actually changes
the behavior of the controller FSM. As a result, the number
of traces has increased in the RTL-FSMD and the condition
of execution of some traces has also changed. As a result, the
equivalence of a few traces of C-FSMD could not be found
in RTL-FSMD. In such a situation, we will analyze to find
a set of traces in RTL-FSMD whose union is equivalent to
the trace in C-FSMD. With further analysis of the condition
of executions of those traces, the DA can be detected. In the
following, we briefly discuss the equivalence checking method
followed by the detection of DA.
B. C-to-RTL Equivalence Checking
The primary challenge in C-to-RTL equivalence checking
is the abstraction gap between the C and the RTL codes.
Therefore, the RTL-FSMD is abstracted from the RTL used in
the equivalence checking method. The input C is represented
as C-FSMD. The construction of the FSMD model from the
C is discussed in detail in [32]. Algorithm 3 is used to the
equivalence between C-FSMD and RTL-FSMD. The equiva-
lence checking method used here is adapted from [15]. The
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
Algorithm 3: C_to_RTL_EqCheck (C, RTL)
Input: C is the input C to HLS, RTL is generated by a HLS
tool from C
Result: Equivalent, detect degradation or downgrade attack
1 M0 = constructFSMD (C);
2 M1 = RTL-FSMD_Extraction(RTL);
3 T0 = findTrace(M0 ); T1 = findTrace(M1 );
4 while (T0 = φ) do
5 τ0 = select a trace from T0 ;
6 TC = getTestcase(τ0 );
7 τ1 = getCorrespondingTrace(T1 , TC);
8 if ((cτ0 ≡ cτ1 ) ∧ (sτ0 ≡ sτ1 )) then
9 //τ0 and τ1 are equivalent
10 removeTrace (τ1 , T1 );
11 end if
12 else if {(cτ0 ∧ cτ1 = φ) ∧ (sτ0 ≡ sτ1 )} then
13 Detect_DA_Attack (τ0 , T1 ); //Algorithm 4 if (not DA)
then
14 Detect_DG_Attack (τ0 , T1 ); //Algorithm 5
15 end if
16 end if
17 else if {(cτ0 ∧ cτ1 = φ) ∧ (sτ0 = sτ1 )} then
18 Detect_DG_Attack (τ0 , T1 ); //Algorithm 5
19 end if
20 removeTrace (τ0 , T0 );
21 end while
22 if (no DA or DG) then
23 Report “No attack is found”;
24 end if
algorithm examines whether the trace pairs of C-FSMD and
RTL-FSMD are equivalent or not. The algorithmic steps are
described briefly below.
1) Generate All Traces in Both the Behaviors: The function
findTrace extracts all the traces of M0 and M1 and assigns
to the sets T0 and T1 , respectively. We have used the tool
Klee [33] for this purpose. We have modified Klee’s source
code to get the symbolic the data transformation (sτ ) and the
condition of execution (cτ ) of each trace τ in M0 and M1 .
2) Find Potential Corresponding Traces Between Two
Behaviors: For checking equivalence between M0 and M1 , we
need to check equivalence between the traces. A naive algo-
rithm will take O(n2 ) comparison (n is the number of traces
in an FSMD) to find the equivalence because it will compare
each trace in M0 with all traces in M1 (to the worst case)
to find the equivalence. To reduce complexity, a data-driven
approach is taken to find the potential corresponding traces
between T0 and T1 . We use Klee tool [] get a test case for
each trace in a behavior. Hence, we know the values of input
variables (test case) for each trace τ0 in T0 . Now, we run M1
with this test case and find the trace τ1 which is followed for
this particular test case. Lines 5–7 of Algorithm 3 implement
this idea. This data-driven approach will reduce the complexity
of equivalence checking to O(n) comparisons.
3) Equivalence Checking of Traces Between Two
Behaviors: Finally, the trace-wise equivalence of poten-
tial correspondent traces is checked using SMT solver Z3
[34] in this work. A potential corresponding trace pair are
equivalent if their respective condition of executions and data
transformations are equivalent (in lines 8–10). If they are
not equivalent, we check possible instances of degradation
or DGs.
 ABDEREHMAN et al.: BLAST: BELLING THE BLACK-HAT HLS TOOL
Algorithm 4: Detect_DA_Attack (τ0 , T1 )
Input: τ0 , T1
Result: Instance of the degradation (Trojan trigger condition)
1 ccomb = φ; //combined condition of traces
2 foreach τi ∈ T1 do
3 // check if cτi is stronger condition than cτ0 and data
transformations match
4 if ((cτi → cτ0 ∧ sτi ≡ sτ0 )) then
5 ccomb = ccomb ∨ cτi ;
6 end if
7 end foreach
8 //check the union of the strong condition cτi is equal to
condition cτ0
9 if (ccomb ≡ cτ0 ) then
10 Report “Possible degradation attack is found in T1 ”.
11 end if
12 else
13 Report “No degradation attack is found in T1 .”
14 end if
C. Detection
We can detect DAs with the help of the equivalence checker
tool. The tool will give us the trace level equivalence between
the C-FSMD and RTL-FSMD. As shown in [1], this bubble
effectively creates an alternative trace in the behavior with
no effective operation inside it. Therefore, our objective is to
identify such spurious traces in the RTL-FSMD. It may be
noted that each of these traces is associated with a condition
(i.e., the trigger of the Trojan) and those conditions are not
present in the initial behavior. During equivalence checking,
therefore, the equivalent trace cannot be found for these traces.
Let p :qi ⇒ qj  be one path from the state qi to qj in the RTL-
FSMD in which the condition to enable the HT is incorporated
by the attacker. In fact, there will be another parallel path (or
a set of paths) from qi in RTL-FSMD which is associated with
the negation of the trigger condition. It is, therefore, possible
to find two (or a set of) traces in RTL-FSMD through qi and
qj whose union will be equivalent to the corresponding trace
in C-FSMD. By analyzing the conditions of these traces, the
HT trigger condition will be identified. The overall DA detec-
tion mechanism is presented in Algorithm 4. Algorithm 4 is
invoked in line 13 of Algorithm 3 when the equivalence of τ0
of M0 and τ1 of M1 cannot be shown because the respective
condition of executions are not equivalent but their intersection
is not NULL (i.e., there is some common condition of execu-
tions between them). In Algorithm 4, we first identify a set of
traces in the RTL-FSMD M1 which has same data transfor-
mation as that of τ0 but each of them has a stronger condition
of execution than that of τ0 of C-FSMD M0 . The stronger
condition of execution is indicated by implication in line 4
of Algorithm 4. Then, we check if the union of condition of
executions of all these traces turns out to be equivalent to the
cτ0 . This indicates that some spurious traces may be added in
the RTL-FSMD by the attacker for implementing DA or DG
attacks. A trace of C-FSMD can also be split into multiple
traces in RTL-FSMD during scheduling as shown in [35]. In
such case, a possible DA attack will be detected which is false
positive. Therefore, a careful manual inspection of the condi-
tion of executions of the traces will identify if any spurious
HT trigger condition is added in the RTL-FSMD.
Example 5: Consider the FSMDs in Fig. 5. During check-
ing equivalence, Algorithm 3 could not found any equivalence
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
3667
(a) (b)
Fig. 6. Example to illustrate the effect of DG.
for a trace τ0 = s1 → s2 → (s3 − →c s4 → s5 −→c s6 →
s3)ntaps → s1 of C-FSMD in Fig. 5(a) in the RTL-FSMD
in Fig. 5(b). Then Algorithm 3 calls Algorithm 4 to check a
possible instance of DA. It found two traces τ1 = t1 → t2 →
(t3 −
→c t4 tj t7 → t5 → t6 −
−
→ →c t3)
ntaps → t1 and τ = t1 → t2 →
2
(t3 −
→c t4 → t5 → t6 −
−
!tj
→
c t3) ntaps → t1 in the RTL-FSMD such
that union of these two traces are equivalent to τ0 and cτ1 and
cτ2 are stronger than cτ0 . After a careful inspection of cτ1 and
cτ2 , we found the trigger condition is tj.
VI. D ETECTION OF D OWNGRADE ATTACK
A compromised HLS tool can inject a malicious function-
ality to access the behaviors of the design. This malicious
functionality can be used by the actual attacker to extract
useful information from the circuit. As a result, the security
properties of the design like cryptography algorithms (AES,
SHA) will be compromised. The level of trust of these algo-
rithms depends on the number of rounds that are executed.
If the algorithms execute some rounds below a given count,
the design becomes vulnerable. It is sufficient to reduce the
number of the executed round in the cryptography algorithms
to compromise the security of the algorithms.
A. Attack Model
DG changes the functionality of the input specification. The
tool might reduce the number of the executed round in secure
hash algorithm (SHA) [36]. This can be done by modifying
the loop constants in the RTL or by preloading a value higher
than 0 as the initial value of the loop iterator. As a result, the
security of the algorithm will be compromised. The value of
the loop constant depends on the trigger signal of the Trojan.
For example, message pairs with a collision can be generated
for the SHA algorithm when the number of a round is reduced
from 64 to 18 [37]. The following example explains the DG
attack.
Example 6: Let us consider the example given in Fig. 6.
Consider the datapath shown in Fig. 6(a). The nb1 is a con-
stant and the i (loop variable) are inputs to the comparator and
the output determines whether the loop body will be executed
or not. We consider only the relevant part of the datapath to
explain the effect of a DG. The datapath is modified as shown
in Fig. 6(b) to introduce the attack. Specifically, an extra con-
stant (i.e., nb2) is introduced and is multiplexed with nb1. The
output of the multiplexer depends on the trigger condition of
the HT. If the trigger condition is True, the loop will iterate
nb2 times instead of nb1 times. The value of the loop bound
is changed based on the trigger condition.
Since the functionality has changed in this attack, the equiv-
alence checking method will find a possible nonequivalence
 3668 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 41, NO. 11, NOVEMBER 2022
(a) (b)
Fig. 7. (a) C Code from AES before adding tj. (b) Representative RTL-C
after DG.
(a) (b)
Fig. 8. Example to illustrate the effect of DG. (a) C-FSMD (M0 ) obtained
from Fig. 7(a). (b) RTL-FSMD (M1 ) obtained from Fig. 7(b).
between the C-FSMD and the RTL-FSMD. In addition to
that, the traces for which equivalence could not be found by
the method will also be reported. These traces correspond to
the block where functional changes are made by the tool.
An attacker in the foundry or a rogue user can activate the
Trojan after a predefined amount of time or by a specific input
sequence. With the careful inspection of this information, the
user can pinpoint the Trojan inserted by the HLS tool.
B. Detection
DG compromises the circuit behavior only when the Trojan
is activated. As long as the Trojan trigger is not activated,
the design produces correct results and the Trojan stays unde-
tected. We use our equivalent checker tool to detect the HT
trigger condition for DG. In DG attack, the number of traces
in M0 and M1 are different due to the HT trigger condition.
Specifically, M1 contains more traces than that of M0 . The
overall DG detection mechanism is presented in Algorithm 5.
Algorithm 5 is invoked in Algorithm 3 when our equivalent
checker could not find equivalent of a trace of τ0 of M0 in
M1 in two scenarios (in lines 13 and 17). In former case
(line 13), the respective condition of executions have some
overlapping but are not equivalent but the data transforma-
tions are equivalent. In the later case (line 17), both condition
of executions and the data transformations are not equiva-
lent. In Algorithm 5, we first identify a set of traces τi in the
RTL-FSMD for which the condition of execution is stronger
(stronger condition is indicated by implication) than that τ0 .
Then, we check if the union of condition of executions of all
these traces ccomb turns out to be equivalent to the condition
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
(a) (b) (c)
Fig. 9. Example to illustrate the effect of DG. (a) Trace of τ00 from C-FSMD
obtained after unrolling (nb = 64). (b) Trace of τ10 from RTL-FSMD obtained
after unrolling (nb = 32). (c) Trace of τ11 from RTL-FSMD obtained after
unrolling (nb = 64).
Algorithm 5: Detect_DG_Attack (τ0 , T1 )
Input: τ0 , T1
Result: Instance of the downgrade (Trojan trigger condition)
1 ccomb = φ; //combined condition of traces
2 foreach τi ∈ T1 do
3 // check if cτi is stronger condition than cτ0
4 if (cτi → cτ0 ) then
5 ccomb = ccomb ∨ cτi ;
6 end if
7 end foreach
8 //check the union of the strong condition ccomb is equal to
condition cτ0
9 if (ccomb ≡ cτ0 ) then
10 Report “Possible downgrade attack is found in T1 ”.
11 end if
12 else
13 Report “No downgrade attack is found in T1 .”
14 end if
of executions of cτ0 . This indicates that some spurious traces
may be added in the RTL-FSMD by the attacker for imple-
menting DG attack. By a careful analysis of the traces involved
in ccomb , we can figure out the spurious HT trigger condition
of the DG and the value of the loop counter is changed.
Example 7: Consider the input C-code and the corre-
sponding RTL-C (after HLS tool inserts Trojan) as shown
in Figs. 7(a) and (b), respectively, and their corresponding
FSMDs are shown Figs. 8(a) and (b), respectively. The traces
of the respective behaviors are shown in Fig. 9. Specifically,
the C-FSMD has one trace and the RTL-FSMD has two traces.
During equivalence checking between traces in M0 and M1 , the
equivalence of τ00 could not be found. But, the algorithm will
select τ10 (or τ11 ) and Algorithm 5 will be called in line 17
(or line 13). Since cτ10 and cτ11 are stronger than cτ00 and
(cτ10 ∨ cτ11 ) ≡ cτ00 , Algorithm 5 will report a possible DG
attack. After a careful inspection of the data transformation
and condition of execution of τ10 and τ11 , we identify that
 ABDEREHMAN et al.: BLAST: BELLING THE BLACK-HAT HLS TOOL
TABLE I
E XPERIMENTAL R ESULTS OF HT D ETECTION FOR D IFFERENT HLS
B ENCHMARKS
the hardware Trigger condition tj and the value of loop count
(variable) are decided by tj. The loop executes a reduced num-
ber of rounds (from 64 to 32) in case of HT is activated. In
addition to loop count, the data transformation of the traces is
also affected by the modification of the loop count.
VII. E XPERIMENTAL R ESULTS
Implementation Detail and Experimental Setups: Our HT
detection framework BLAST is implemented in Python. The
BLAST first extracts an abstract syntax tree (AST) from the
Verilog using the pyVerilog [38] parser and then implemented
the rewriting method on the AST to obtain the RTL-FSMD.
Specifically, we have adapted the FastSim [14] to extract the
RTL-FSMD in our work. The RTL-FSMD of our flow and
the RTL-C of FastSim represents the same reverse engineering
high-level behavior of RTL. The C-FSMD is extracted from
the input C behavior. For identifying traces in an FSMD, we
have used Klee [33] and for checking the equivalence of traces
between two FSMDs, we have used SMT solver Z3 [34]. The
experiments have been performed on a machine with a CPU:
Intel Core i7, 2.5 GHz, and 8 GB RAM on a set of HLS
benchmarks. We have used the Vivado HLS tool [39] to gen-
erate Verilog RTL for the benchmarks written in C. We then
manually inserted all three HTs (BE, degradation, and DGs)
on the RTLs and generate various versions of the RTL.1 The
HTs are inserted by the following logic presented in [1]. We
have not added any trigger circuit in the RTLs to activate the
HTs. Instead, we assume the trigger condition as an input. We
perform the RTL simulation to ensure the functional correct-
ness of the modified RTLs when the HTs are not activated and
the desired behaviors when the HTs are activated.
Experiments: We evaluated our method on a variety of
HLS benchmarks [Waka, Motion, Parker, Array add, Find min,
FMM, and auto-regressive lattice filter with branch (ARFNC)
1 The BlackHat HLS tool [1] is not available online. Therefore, we have
implemented the same idea on the Vivado HLS generated RTLs.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
3669
and without branch (ARFNB)], each of them is written in
C-code. The benchmarks are taken from the distribution of
Bambu HLS [40]. The experimental results of our bench-
marks are shown in Table I. The second (type) and third
(#C) columns show the type of attacks and the number of
input C code lines for each benchmark, respectively. We have
recorded the number of code lines (#RTL) of RTL and the
number of code lines (#RTLC) of RTL-C in fourth and fifth
columns, respectively. The sixth and seventh columns are the
trace count (#TC) in the source C and RTL-C, respectively. It
may be noted that the trace count is not measured for BE
attack since it is identified in RTL-FSMD extraction. The
number of instance (#instance) of HT insertion is given in
column eighth. The column ninth represents the HT detection
time by our tool BLAST. Each row (BE/DA/DG) represents
a BE/degradation/downgrade HT scenarios created from the
original RTL. In the case of a BE attack, the detection time is
less compared to other attacks because BE attack is identified
during the FSMD extraction phase. The equivalence check-
ing is not needed to detect BE attack. For FMM, although
the number of traces are high, the BE attack is detected in
quick time. The DA attack detection time is much higher as
compared to BE attack detection for FMM. The DA attack
detection time for Parker, Find_min and FMM is higher as
compared to the DA attack detection in other test cases since
the number of traces is more in these cases. As a result, equiv-
alence checking is taking more time. In all cases, HT attacks
are correctly detected by our proposed method. Generally, the
detection time for our framework is not high. We have tested
that the runtime of our tool is not much impacted by the appli-
cations of HLS optimizations on our benchmarks since the
overall steps to be checked are mostly the same in all cases.
HT Overheads: We synthesized the original RTL code [RTL
(original)], the RTL code after inclusion of HTs [RTL(HTs)] to
check the resource utilization overheads of HT implementa-
tion. We evaluated the attacks implemented in Vivado HLS
generated RTL code. In this experiment, we reported the
scenario from Table I on which the overhead is maximum.
For example, among three scenarios of Parker in Table I, we
reported the BE scenario since overhead was maximum in BE
among the three scenarios of Parker. All the designs were syn-
thesized for Virtex4 XC4VCX15 series FPGA. From device
utilization summary report obtained after synthesis, we cal-
culate the overhead (Slices, Flipflop, and LUT) needed by
the additional logic added to implement HTs in the origi-
nal RTL with respect to the available resource in the device.
Table II presents the device utilization summary and maxi-
mum area overhead of RTL (HTs) as compared to the RTL
(original) for bigger test cases. As shown, the hardware needed
to implement RTL (HTs) is slightly more than the hardware
needed to implement RTL (original). The area overhead is
less than 1% in most cases. In general, these results show
that the HTs minimally impact the area. Similarly, minimum
input arrival time before clock (MIATBC), maximum output
required time after clock (MORTAC), and maximum combi-
national path delay (MCPD) of RTL (BE) and RTL (DA) as
compared to RTL (original) obtained from timing report after
synthesis are reported Table III. As shown in the table, the
delay is increased by an average of 1ns for all the scenarios.
We have not reported the DG scenarios here since the results
were similar. Hence, we conclude that the extra logic added to
implement HTs into the original RTL minimally impacts the
area and speed of the design.
 3670 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 41, NO. 11, NOVEMBER 2022
TABLE II
C OMPARISONS OF A REA OVERHEAD FOR RTL (O RIGINAL ) W ITH
R ESPECT T O THE RTL (HT S )
TABLE III
C OMPARISONS OF I NCREASE IN D ELAY FOR RTL (O RIGINAL ) W ITH RTL
(BE) AND RTL (DA)
VIII. P ERFORMANCE OF BLAST FOR HLS
O PTIMIZATIONS
Modern day HLS tools are equipped with various soft-
ware and hardware-oriented optimizations to provide efficient
hardware from a given C/C++ behavior. In the front-end
of the HLS tool, a compiler like GCC or LLVM is used
to parse the input behavior. Since these C/C++ compilers
consist of hundreds of software code optimizations, they are
now available in the HLS tool. On the other hand, the HLS
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
tool applies various hardware-oriented optimizations like array
partitioning, loop pipelining, loop unrolling, data flow opti-
mizations, etc. in the back-end of HLS to make the input
C/C++ code hardware efficient. In this section, we have ana-
lyzed how HLS optimizations affect the performance of the
BLAST framework.
The BLAST has two phases—an RTL-FSMD extraction
phase and a C-to-RTL equivalence checking phase. The RTL-
FSMD extraction phase is relied on the FastSim [14] tool. This
tool is equipped to handle all kinds of optimizations applied in
HLS. To detect BE attack, BLAST essentially adds a module
(i.e., Algorithm 2) in FastSim flow to analyze the BE attack
in presence of bit-flipped operations in a state as discussed
in Section IV-C. Therefore, the BE attack can be detected by
BLAST irrespective of what HLS optimizations are applied
by the HLS tool. Since BLAST analyzes the RTLs generated
by the HLS tool in a state wise manner of the controller FSM,
the run time of BE attack detection is not impacted much by
the applications of HLS optimizations. Usually, the BE attack
is identified in milliseconds.
The DA and DG attacks detection rely on the C-to-RTL
equivalence checking in which the RTL-FSMD extracted in
phase one is formally compared with the input C behavior (i.e.,
C-FSMD). Since BLAST checks the trace level equivalence
between these two behaviors, a major change in the control
flow due to HLS optimizations will impact DA and DG attacks
detection probability. The front-end optimizations like con-
stant propagation, copy propagation, common subexpression
elimination, dead code elimination, static single assignment,
code motion, operator strength reduction (e.g., multiplication
by constant is replaced by left shift by constant), etc. mostly
impact the data dependence in the behavior. Such optimiza-
tions do not impact much on the control flow of the input
behavior. Therefore, the performance of BLAST won’t be
impacted by applications of such software optimizations in
the front-end of the HLS.
Let us now discuss the hardware oriented optimizations.
The array partitioning essentially breaks an array into multiple
arrays to map them into multiple RAMs in order to improve
memory access time. The array merging is the reverse process
of array partitioning. In our case, the RAMs are represented as
arrays in RTL-FSMD. So, we have two behaviors where the
number of intermediate arrays is different. The control struc-
ture of the input behavior is not impacted by this optimization.
Therefore, array partitioning/merging won’t impact our DA
and DG detection. Loop unrolling unrolls the loop of input C.
In Algorithm 3, we use Klee to identify traces in the behav-
iors. Klee unrolls loops to identify the traces. Although loop
unrolling changes the control structure, it won’t impact the
detection of DA and DG attacks in BLAST since loops are
unrolled during detection.
The loop pipelining creates multiple stages within a state
where each stage works on the data of different iterations of
the loop. This helps in running the multiple iterations of the
loop in parallel to improve the latency. For a pipelined func-
tion, the pipelined stages work in similar manner. The FastSim
creates sequential representation of the pipelined stages with
suitable logic to handle the inherent dataflow among the sub-
sequent stages. Consider the example in Fig. 10 to understand
the fact. Assume the operations within a loop body are sched-
uled in three pipeline stages as shown in Fig. 10(a). The
corresponding RTL-FSMD behavior is shown in Fig. 10(b).
Each pipeline stage is activated by a flag. In the first clock,
 ABDEREHMAN et al.: BLAST: BELLING THE BLACK-HAT HLS TOOL
Fig. 10. Representation of pipelined loop in C.
only stage 1 is active and in the second clock both stage 1
and stage 2 are active. From third clock, all stages are active.
FastSim copies the value of each intermediate variable into a
temporary variable and uses them in the right-hand expression
of the operations. Consequently, at ith clock, stage 1 works
on ith inputs, stage 2 works on the (i − 1)th data and state 3
works on (i − 2)th data. During equivalence checking between
C-FSMD and RTL-FSMD, such pipelined loop will result in
a single trace. The corresponding loop of C-FSMD is also
results in a single trace. Thus, there won’t be any change in
the control flow between C-FSMD and RTL-FSMD in pres-
ence of loop pipelining. Therefore, BLAST can detect DA and
DG attacks in presence of loop and function pipelinings.
In data-flow optimization, the producer-consumer relation
between various modules in the input C code is identified
and such modules are executed in parallel in RTL. The first-
in-first-out (FIFO) or Ping-Pong buffer is used between a
producer-consumer pair for asynchronous data communication
between them. To model such parallel behavior in RTL-FSMD
(which is a sequential behavior), we extract the FSMD of
each module first. We then generate a global RTL-FSMD in
which one of the states of each module will be executed in
each clock.2 The next state to be executed in a module is
determined by the state transition of RTL-FSMD of the corre-
sponding module. The detail of such modeling may be found
in [14]. Since the control flow of the RTL-FSMD in presence
of data flow optimization is completely different from that of
the C-FSMD, BLAST cannot detect DA or DG attach in such
a scenario. Specifically, Algorithm 3 returns false-negative (in
line 23) if dataflow optimizations are applied. In general, if the
control flow of the input behavior is modified significantly by
HLS, BLAST may return false-negative results. We have used
Klee to obtain the traces in a program (line 3 of Algorithm 3)
and Z3 SMT solver for checking the equivalence of traces in
our Algorithms. So, the run time of BLAST largely depends
on these two tools to detect DA and DG attacks.
IX. C ONCLUSION
In this article, we presented the BLAST framework to detect
HLS tool inserted HT in the RTL. The strength in our detec-
tion framework is the ability to construct a C-like behavioral
specification from the RTL generated by the HLS tool. This
helps us to correlate the RTL with the input C-specification.
We have shown that all three Trojan inserted by the Black-
hat HLS tool are detected in our framework. Our framework
will report the possible instances of the HTs. The developer
can identify the actual HT with further analysis. We have also
2 Since RTL-FSMD is a cycle accurate model, operations executed in each
clock can be tracked.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.
3671
analyzed the area and delay overheads of our benchmarks. We
concluded that the inclusion of HTs minimally impact the area
and the delay. The experimental results for a commercial HLS
tool for several HLS benchmarks show that our method can
efficiently detect the attacks automatically without taking any
information from the HLS tool.
Based on the impact of HTs, they can be categorized
into: 1) change functionality; 2) degrade performance; 3) leak
information; and 4) denial of service. While denial of service
type HT will be hard to implement at HLS, the others HTs
are possible. In fact, the BE attack degrades performance by
consuming more power, DA attack degrades performance by
increasing the latency of the design and the DG attack changes
the functionality. Similar to BE and DA attacks, the other
attacks can also be formulated to leak information about secret
data in terms of power or latency. The novelty of our work lies
with the fact that we have identified the generic impacts of the
HTs at higher abstraction level. Specifically, the HTs results
in either 1) executing spurious bit-flipping operations around
an idle FUs in a state or 2) any HT trigger condition effec-
tively creates branches in the controller FSM. This results in a
situation where a set of traces are created from a single trace
of the input behavior. The approach proposed in this paper are
trying to find these two scenarios. Therefore, BLAST should
able to detect any kind of HTs that changes functionality or
degrades performance or leaks information.
R EFERENCES
[1] C. Pilato, K. Basu, F. Regazzoni, and R. Karri, “Black-hat high-level
synthesis: Myth or reality?” IEEE Trans. Very Large Scale Integr. (VLSI)
Syst., vol. 27, no. 4, pp. 913–926, Apr. 2019.
[2] H. Stefan, K. Sri, and P. Dickon, Creating Value in the Semiconductor
Industry. New York, NY, USA: McKinsey, Aug. 2011, pp. 1–15.
[3] P. Coussy, D. D. Gajski, M. Meredith, and A. Takach, “An introduc-
tion to high-level synthesis,” IEEE Design Test Comput., vol. 26, no. 4,
pp. 8–17, Jul./Aug. 2009.
[4] B. Bailey. “Is High-Level Synthesis Ready for Prime Time?” Jun. 2012.
[Online]. Available: http://www.edn.com/design/integrated-circuit-desig
n/4375454/Is-high-level-synthesis-ready-for-prime-time
[5] J. Cong, B. Liu, S. Neuendorffer, J. Noguera, K. Vissers, and Z. Zhang,
“High-level synthesis for FPGAs: From prototyping to deployment,”
IEEE Trans. Comput.-Aided Design Integr. Circuits Syst, vol. 30, no. 4,
pp. 473–491, Apr. 2011.
[6] R. Karri, J. Rajendran, K. Rosenfeld, and M. Tehranipoor, “Trustworthy
hardware: Identifying and classifying hardware trojans,” Computer,
vol. 43, no. 10, pp. 39–46, Oct. 2010.
[7] K. Basu et al., “CAD-base: An attack vector into the electronics sup-
ply chain,” ACM Trans. Design Autom. Electron. Syst., vol. 24, no. 4,
pp. 1–30, Apr. 2019.
[8] S. Bhunia and M. M. Tehranipoor, The Hardware Trojan War: Attacks,
Myths, and Defenses. Cham, Switzerland: Springer, Jan. 2018.
[9] M. Hicks, M. Finnicum, S. T. King, M. M. K. Martin, and J. M. Smith,
“Overcoming an untrusted computing base: Detecting and remov-
ing malicious hardware automatically,” in Proc. IEEE S P, 2010,
pp. 159–172.
[10] U. Alsaiari and F. Gebali, “Hardware trojan detection using reconfig-
urable assertion checkers,” IEEE Trans. Very Large Scale Integr. (VLSI)
Syst., vol. 27, no. 7, pp. 1575–1586, Jul. 2019.
[11] C. Bao, D. Forte, and A. Srivastava, “Temperature tracking: Toward
robust run-time detection of hardware trojans,” IEEE Trans. Comput.-
Aided Design Integr. Circuits Syst., vol. 34, no. 10, pp. 1577–1585,
Oct. 2015.
[12] N. Fern and K. T. Cheng, “Evaluating assertion set completeness to
expose hardware trojans and verification blindspots,” in Proc. DATE,
Mar. 2019, pp. 402–407.
[13] W. Chen, S. Ray, J. Bhadra, M. Abadir, and L.-C. Wang, “Challenges and
trends in modern SoC design verification,” IEEE Design Test, vol. 34,
no. 5, pp. 7–22, Oct. 2017.
 3672 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 41, NO. 11, NOVEMBER 2022

[14] M. Abderehman, J. Patidar, J. Oza, Y. Nigam, T. A. Khader, and
C. Karfa, “FastSim: A fast simulation framework for high-level
synthesis,” IEEE Trans. Comput.-Aided Design Integr. Circuits Syst.,
vol. 41, no. 5, pp. 1371–1385, May 2022.
[15] M. Abderehman, T. R. Reddy, and C. Karfa, “DEEQ: Data-driven end-
to-end EQuivalence checking of high-level synthesis,” in Proc. 23rd
ISQED, 2022, pp. 64–70.
[16] S. Bhasin and F. Regazzoni, “A survey on hardware trojan detection
techniques,” in Proc. ISCAS, 2015, pp. 2021–2024.
[17] S. Bhasin, J.-L. Danger, S. Guilley, X. T. Ngo, and L. Sauvage,
“Hardware trojan horses in cryptographic IP cores,” in Proc. Workshop
Fault Diagnosis Tolerance Cryptogr., 2013, pp. 15–29.
[18] S. Jha and S. Jha, “Randomization based probabilistic approach to detect
trojan circuits,” in Proc. 11th IEEE High Assurance Syst. Eng. Symp.,
2008, pp. 117–124.
[19] H. Salmani, M. Tehranipoor, and J. Plusquellic, “A novel technique
for improving hardware trojan detection and reducing trojan activation
time,” IEEE Trans. Very Large Scale Integr. (VLSI) Syst., vol. 20, no. 1,
pp. 112–125, Jan. 2012.
[20] D. Agrawal, S. Baktir, D. Karakoyunlu, P. Rohatgi, and B. Sunar, “Trojan
detection using IC fingerprinting,” in Proc. IEEE SP, 2007, pp. 296–310.
[21] Y. Liu, K. Huang, and Y. Makris, “Hardware trojan detection through
golden chip-free statistical side-channel fingerprinting,” in Proc. DAC,
2014, pp. 1–6.
[22] G. Bloom, B. Narahari, and R. Simha, “OS support for detecting trojan
circuit attacks,” in Proc. HOST, 2009, pp. 100–103.
[23] C. Karfa, D. Sarkar, C. Mandal, and C. Reade, “Hand-in-hand verifica-
tion of high-level synthesis,” in Proc. GLSVLSI, 2007, pp. 429–434.
[24] S. Kundu, S. Lerner, and R. K. Gupta, “Translation validation of high-
level synthesis,” IEEE Trans. Comput.-Aided Design Integr. Circuits
Syst., vol. 29, no. 4, pp. 566–579, Apr. 2010.
[25] K. Banerjee, C. Karfa, D. Sarkar, and C. Mandal, “Verification of code
motion techniques using value propagation,” IEEE Trans. Comput.-Aided
Design Integr. Circuits Syst., vol. 33, no. 8, pp. 1180–1193, Aug. 2014.
[26] R. Chouksey, C. Karfa, and P. Bhaduri, “Translation validation of code
motion transformations involving loops,” IEEE Trans. Comput.-Aided
Design Integr. Circuits Syst., vol. 38, no. 7, pp. 1378–1382, Jul. 2019.
[27] R. Chouksey and C. Karfa, “Verification of scheduling of conditional
Behaviors in high-level synthesis,” IEEE Trans. Very Large Scale Integr.
(VLSI) Syst., vol. 28, no. 7, pp. 1638–1651, Jul. 2020.
[28] C. Karfa, D. Sarkar, C. Mandal, and C. Reade, “Register sharing verifi-
cation during data-path synthesis,” in Proc. ICCTA, 2007, pp. 135–140.
[29] C. Karfa, D. Sarkar, and C. Mandal, “Verification of Datapath and
controller generation phase in high-level synthesis of digital circuits,”
IEEE Trans. Comput.-Aided Design Integr. Circuits Syst., vol. 29, no. 3,
pp. 479–492, Mar. 2010.
[30] D. Gajski and L. Ramachandran, “Introduction to high-level synthe-
sis,” IEEE Trans. Design Test Comput., vol. 11, no. 4, pp. 44–54, 1994.
[Online]. Available: https://ieeexplore.ieee.org/document/329454
[31] Z. Manna, Mathematical Theory of Computation. Tokyo, Japan:
McGraw-Hill Kogakusha, 1974.
[32] C. Karfa, C. Mandal, and D. Sarkar, “Formal verification of code motion
techniques using data-flow-driven equivalence checking,” ACM Trans.
Design Autom. Electron. Syst., vol. 17, no. 3, p. 30, 2012.
[33] C. Cadar, D. Dunbar, and D. Engler, “KLEE: Unassisted and automatic
generation of high-coverage tests for complex systems programs,” in
Proc. OSDI, Dec. 2008, pp. 209–224.
[34] “Z3—The SMT solver.” Accessed: May 21, 2022. [Online]. Available:
https://github.com/Z3Prover/z3
[35] O. Peñalba, J. M. Mendías, and R. Hermida, “A global approach to
improve conditional hardware reuse in high-level synthesis,” J. Syst.
Archit., vol. 47, no. 12, pp. 959–975, Jun. 2002.
[36] “Secure hash standard—SHS: Federal information processing, standard
FIPS 180-4, U.S. department of commerce and national institute of stan-
dards and technology (NIST).” 2012. https://csrc.nist.gov/publications/
detail/fips/180/4/final
[37] S. K. Sanadhya and P. Sarkar, “Attacking reduced round SHA-256,”
in Applied Cryptography and Network Security. Heidelberg, Germany:
Springer, 2008, pp. 130–143.
[38] S. Takamaeda-Yamazaki, “Pyverilog: A Python-based hard-
ware design processing toolkit for verilog HDL,” in Applied
Reconfigurable Computing (Lecture Notes in Computer Science
9040). Cham, Switzerland: Springer Int., Apr. 2015, pp. 451–460,
doi: 10.1007/978-3-319-16214-0_42.
[39] “Vivado high-level synthesis.” Accessed: May 21, 2022. [Online].
Available: http://xilinx.com/support/download.html
[40] “Bambu tool reference.” Accessed: May 21, 2022. [Online]. Available:
https://panda.dei.polimi.it/
Mohammed Abderehman received the B.Tech.
degree in computer engineering from Defence
University, Engineering College, Bishoftu, Ethiopia,
in 2011, and the M.Tech. degree from the Defence
Institute of Advanced Technology, Pune, India, in
2014. He is currently pursuing the Ph.D. degree
with the Indian Institute of Technology Guwahati,
Guwahati, India.
His current research interests include the verifica-
tion of high-level synthesis, hardware security, and
embedded system.
Rupak Gupta received the B.E. degree in computer
science and engineering from M.I.T.M Indore (Rajiv
Gandhi Proudyogiki Vishwavidyalaya), Indore,
India, in 2018, and the M.Tech. degree in computer
science and engineering from IIT Guwahati,
Guwahati, India, in 2021.
He is currently working as a Software Engineer
with Amagi Media Labs, Bengaluru, India. His
current research interests include hardware trojan
detection, reverse engineering register to variable
mapping and RTL to C equivalence checking.
Rakesh Reddy Theegala received the B.Tech.
degree from IIT Guwahati, Guwahati, India, in
2021.
He is working as a Google Software Engineering,
IIT Guwahati. His current interest includes RTL to
C equivalence checking.
Chandan Karfa (Senior Member, IEEE) received
the M.S. and Ph.D. degrees in computer science
and engineering from IIT Kharagpur, Kharagpur,
India, in 2007 and 2011, respectively.
He has worked for five years as an Sr. R&D
Engineer with Synopsys (India) Pvt. Ltd.,
Bengaluru, India. He is currently working as
an Associate Professor with the Department of
Computer Science and Engineering, IIT Guwahati,
Guwahati, India. He has published more than fifty
research papers in reputed international journals
and conferences. His research interests include formal verification, high-level
synthesis, hardware security, and formal methods.
Dr. Karfa has received the Qualcomm Faculty Award from Qualcomm in
2021, the TechnoInventor Award by India Electronics and Semiconductor
Association in 2014, the Innovative Student Projects Award from Indian
National Academy of Engineers in 2008 and 2013, the Best Paper Awards
in ADCOM Conference in 2007 and in I-CARE conference in 2013, and the
Microsoft Research India Ph.D. Fellowship in 2008.

Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY GUWAHATI. Downloaded on May 11,2023 at 11:01:43 UTC from IEEE Xplore. Restrictions apply.