01-intro.tex 6.53 KB
Newer Older
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's avatar
Stefan Tauner committed
8
In contrast to fault injection tests by modification of the \ac{RTL} source,
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.