Biblio

Hardware Trojans (HTs) are malicious modifications of the original circuits intended to leak information or cause malfunction. Based on the Side Channel Analysis (SCA) technology, a set of hardware Trojan detection platform is designed for RTL circuits on the basis of HSPICE power consumption simulation. Principal Component Analysis (PCA) algorithm is used to reduce the dimension of power consumption data. An intelligent neural networks (NN) algorithm based on Particle Swarm Optimization (PSO) is introduced to achieve HTs recognition. Experimental results show that the detection accuracy of PSO NN method is much better than traditional BP NN method.

As a problem solving method, neural networks have shown broad applicability from medical applications, speech recognition, and natural language processing. This success has even led to implementation of neural network algorithms into hardware. In this paper, we explore two questions: (a) to what extent microelectronic variations affects the quality of results by neural networks; and (b) if the answer to first question represents an opportunity to optimize the implementation of neural network algorithms. Regarding first question, variations are now increasingly common in aggressive process nodes and typically manifest as an increased frequency of timing errors. Combating variations - due to process and/or operating conditions - usually results in increased guardbands in circuit and architectural design, thus reducing the gains from process technology advances. Given the inherent resilience of neural networks due to adaptation of their learning parameters, one would expect the quality of results produced by neural networks to be relatively insensitive to the rising timing error rates caused by increased variations. On the contrary, using two frequently used neural networks (MLP and CNN), our results show that variations can significantly affect the inference accuracy. This paper outlines our assessment methodology and use of a cross-layer evaluation approach that extracts hardware-level errors from twenty different operating conditions and then inject such errors back to the software layer in an attempt to answer the second question posed above.