01-intro.tex 6.53 KB
 Stefan Tauner committed May 04, 2018 1 2 3 4 5 6 7 \section{Introduction} The target audience of this documents are hardware and test engineers that want to evaluate or use the \ac{FIJI} suite. Some technical details that are supposedly irrelevant to ordinary users are omitted on purpose and can be looked up in the accompanying \hyperref[TRM:first_page]{\ac*{TRM}}. The \ac{FIJI} suite provides a tool flow for performing fault injection tests on chip designs in an FPGA-based environment.  Stefan Tauner committed May 04, 2018 8 In contrast to fault injection tests by modification of the \ac{RTL} source,  Stefan Tauner committed May 04, 2018 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 \ac{FIJI} targets the already synthesized design at the FPGA primitive level (e.g., \acp{LUT}, Flip-Flops, and the nets connecting them). Compared to fault injection carried out with the help of partial reconfiguration, \ac{FIJI} is relatively technology-independent as no knowledge about the bitstream format and the mapping to configuration frames within the FPGA device is required. \Cref{fig:fiji_overview} depicts a complete \ac{FIJI} system comprising the \ac{DUT} (bottom right), together with the \ac{FIJI} logic (top right) in an FPGA connected to a controlling host computer (left). \begin{figure}[!htb] \centering \includegraphics[width=0.95\linewidth]{../tex_common/img/Overview.pdf} \caption{\ac{FIJI} Overview} \label{fig:fiji_overview} \end{figure} \ac{FIJI} works by instrumenting individual nets of a given netlist of a \ac{DUT} with fault injection logic according to a predefined fault injection configuration. For each affected net there exists exactly one \ac{FIU} that can alter the respective signal. A single \ac{FIC} manages the other components of the \ac{FIJI} logic. It can be parametrized to fit the original design and required test properties for low resource usage. The \ac{FIC} is connected with a host computer via a \ac{UART} unit to allow remote changes of the \ac{FIU} configurations and control the execution of the system. \subsection{Fault Modes} The \acp{FIU} can be configured to forward the following signal types: \begin{itemize} \item Original signal (no fault) \item Stuck at 0 level \item Stuck at 1 level \item Original signal delayed by one clock (models delay fault) \item Inversion of the original signal for a single clock cycle (models \acp{SEU}) \item Pseudo-random data (models stuck-open faults) \end{itemize} An overview of the effects of each fault model can be seen in \Cref{fig:faulttiming}. \begin{figure}[ht] \centering \input{img/fault_modes.tex} \caption{Timing Diagrams for Fault Modes} \label{fig:faulttiming} \end{figure} \subsection{Triggering Options} There are several reset and triggering options: Either the \ac{FIC} can (on the host's command) reset the \ac{DUT}, or the \ac{DUT} may reset the FI logic. Naturally only either one of these options can be selected at build time to prevent infinite reset loops. Additionally, the FI logic’s reset may be routed to an I/O pin to be activated externally. Injected faults can be deferred until a trigger signal fires. The source of this signal can be changed at runtime and may be an external pin or a signal from the \ac{DUT}. Optionally, two signals of the \ac{DUT} can be selected to provide the \ac{FIC} with fault detection information. Which nets in the \ac{DUT} are suitable to provide this information depends on the application. If the application contains some kind of fault detection logic, for example, the outputs of this module can be used. \subsection{Tool Flow Overview} In \Cref{fig:fiji_flow_overview} a concise overview of the \ac{FIJI} tool flow is depicted starting with an existing Synopsys Synplify project containing the user HDL design on the left. \begin{figure}[!htb] \centering \input{../tex_common/img/fiji_flow_overview} \caption{Overview of the \ac{FIJI} Tool Flow} \label{fig:fiji_flow_overview} \end{figure} The design is first synthesized with Synplify into a Verilog post-synthesis netlist before configuration can start. The generation of the \ac{FIJI} settings representing the overall fault injection configuration and the parametrization of the \ac{FIC} is aided by the graphical user interface provided by the \textit{\ac{FIJI} Setup} tool named \texttt{fiji\_setup.pl}. In the next step \texttt{fiji\_instrument.pl} modifies the original netlist and generates a wrapper around it. The resulting design is then synthesized again with Synplify and subjected to P\&R to create the final FPGA configuration bitstream. At this point the design is ready to be installed in an FPGA. Test execution is facilitated by the \textit{\acf{FIJIEE}} either via command line (\texttt{fiji\_ee.pl}) or its GUI (\texttt{fiji\_ee\_gui.pl}). Both of these tools support the execution of individual manually specified tests, predefined sequences, and random tests. \subsection{Execution Overview} The actual fault injection process can be divided into five phases. The execution of these phases is handled by the \ac{FIC} based on the arrival of configuration data from the host, a timer and a trigger signal. Each configuration pattern specifies fault patterns for two consecutive time periods. A graphical representation of these phases is shown in \Cref{fig:fiji_phases_overview}. \begin{figure}[!htb] \centering \input{img/fiji_phases_overview} \caption{Phases of Execution} \label{fig:fiji_phases_overview} \end{figure} First (in the \textit{CONF} phase), the host has to transmit a new configuration to the hardware. The \ac{FIC} stores parts of the configuration internally and forwards the parts relevant to the FIUs into temporary registers within the \acp{FIU}. When the previously active injection process ends, the \ac{FIC} can start a new one according to this buffered configuration information. At the begin of the second phase (\textit{WAIT}) the \ac{FIC} resets the \ac{DUT}, if configured to do so. Optionally it then waits for a trigger signal before starting the next phase. The duration of the \textit{COUNT} phase depends on the configuration value sent by the host. This allows to precisely time the starting point of the injection of the first fault pattern relatively to the trigger (if activated) or to the reception of the respective configuration data. When the timer finishes counting down, the \ac{FIC} instructs the \acp{FIU} to adopt the first fault pattern and starts the \textit{FAULT1} phase: The timer counts down from a second configuration value, while the first fault pattern is active. When the timer finishes counting down the second time, the \ac{FIC} instructs the \acp{FIU} to activate the second fault pattern and thus starts \textit{FAULT2}. This pattern remains active until the next configuration is received and activated.