Commit 92e2a0eb authored by Christian Fibich's avatar Christian Fibich Committed by Stefan Tauner
Browse files

Further translate TR to LaTeX TRM

parent b72e6ff1
\acro{LOC}{Lines Of Code}
\acro{FIJI}{Fault InJection Instrumenter}
\acro{FIU}{Fault Injection Unit}
\acro{FIC}{Fault Injection Controller}
\acro{DUT}{Design under Test}
\acro{UART}{Universal Asynchronous Receiver Transmitter}
\acro{LFSR}{Linear Feedback Shift Register}
\acro{WWW}{World Wide Web}
Silence bibtex error \cite{adams2007hitchhiker}
FIJI allows to instrument user-selected nets of an existing FPGA design
with fault injection units (\acp{FIU}). For each affected net there exists
exactly one \ac{FIU} that can alter the respective signal. A single,
resource-efficient \ac{FIC} allows to configure the \acp{FIU} at runtime.
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.
\caption{FIJI Overview}
The FIUs can inject the following:
\item Original signal (no fault)
\item Stuck at 0 level
\item Stuck at 1 level
\item Original signal delayed by one clock (models delay faults)
\item Inversion of the original signal for a single clock cycle (models single event upsets)
\item Pseudo-random data (models stuck-open faults)
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 either 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 can be selected to provide 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{Execution Overview}
The whole configuration and injection process can be divided into five
phases. The execution of these phases is handled by the FIC based on
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.
A graphical representation of these phases is shown in Figure~\ref{fig:fi_seq}.
First (in the \textit{CONF} phase), the host has to transmit a new configuration
to the hardware. The FIC stores parts of the configuration internally
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 FIUs. When the previously active injection process ends,
the FIC can start a new one according to this buffered configuration information.
the \ac{FIC} can start a new one according to this buffered configuration information.
At the begin of the second phase (\textit{WAIT}) the FIC resets the DUT, if
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.
......@@ -28,10 +59,50 @@ 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 FIC instructs the FIUs to
When the timer finishes counting down, the \ac{FIC} instructs the FIUs 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 FIC instructs the FIUs to activate the second fault pattern
time, the \ac{FIC} instructs the FIUs to activate the second fault pattern
and thus starts \textit{FAULT2}. This pattern remains active until the next
configuration is received and activated.
\caption{Phases of Execution}
\subsection{Tool Flow Overview}
In Figure~\ref{fig:fijiflow} the tool flow of FIJI is depicted. The main input of FIJI
is an existing Synopsys Synplify project containing the user HDL design.
The design is first synthesized with Synplify into a Verilog post-synthesis
netlist. Then the engineer executes \texttt{fiji\} to select the nets to
be instrumented and to set global configuration options (e.g., design clock
frequency). This information is stored in the FIJI Settings.
\texttt{fiji\} uses this configuration data to output an altered
netlist of the original design. Within this instrumented netlist all
previously selected nets are broken up and routed out of the entity.
The script also generates a new top-level wrapper that instantiates the
instrumented design and channels the exported signals through dedicated
FIUs and back into the user design. The resulting design is then synthesized
again and is then subjected to P\&R to create the final FPGA configuration
At this point the design is ready to be installed in an FPGA and can
interact with \texttt{fiji\} and \texttt{fiji\_ee\}.
These scripts allows to interactively configure the FI system based
on the global settings stored by the previous elements of the tool
chain. Alternatively, \texttt{fiji\} can also be completely
controlled via its command line interface to allow for automated
\caption{\ac{FIJI} Tool Flow}
\section{Tool Flow and Settings}
\ No newline at end of file
\section{Tool Flow and Settings}
The framework is highly configurable and consists of various parts that
require access to configuration parameters (see tables at the end of the chapter for a complete list).
\subsection{FIJI Setup Tool}
The \ac{FIJI} Settings file (usually named fiji.cfg) serves as intermediate
storage for the parameters and is read by the various tools of the framework.
It is normally created by \texttt{fiji\} from the synthesized netlist of
the user design and input from the user. It acquires information about
the DUT and the to be inserted faults by querying the engineer for the
following data:
\item Design settings:
\item Name of the clock net within the DUT to be used as input for the FIC and its frequency,
\item UART baud rate,
\item Width of the timer (determining the maximum time spans of the t1 and t2 durations),
\item Width, polynomial, seed of the linear feedback shift register (LFSR) that is used to generate pseudo randomness,
\item Activation, polarity, name of external reset
\item Activation, polarity, name of DUT-to-FIC reset signal
\item Activation, polarity, name, duration of FIC-to-DUT reset signal
\item Activation, polarity, name of internal trigger input
\item Activation, polarity, name of external trigger input
\item ``FPGA Implementation'' tool (and other target-related information?)
\item Name for serial RX and TX signals
\item For each ``faulty'' net (thereby specifying the number of \acp{FIU}
\item Net name
\item Net driver
\item Fault models (all 5 fault models or one (selected) of them (cf. Table~\ref{tab:faultmodels})
\item Bits of global \ac{LFSR} which should be ANDed to generate the random fault in
stuck-open mode
The detailed specification of the values and syntax of the \ac{FIJI} Settings
can be found in Section~TODO. Any module-specific parameters (e.g. generics
for hardware modules) are described within the respective chapters later.
\subsection{FIJI Instrumentation Tool}
The next tool in the flow is \texttt{fiji\} that instruments the given
user design according to the information in the \ac{FIJI} Settings. \todo{TBC}
Additionally, the script calculates a design ID each time it creates a
new netlist. This ensures that configuration data sent to the hardware
matches the actual design. To this end it calculates a 16-bit hash value
with the \ac{FIJI} Settings and the unmodified net list as input (\todo{how exactly}).
Appropriate constraints are added to prevent unwanted optimizations that would interfere with the introduced faults.
\todo{upon instrumentation, launch Synplify for further processing...}
\subsection{FIJI Execution Engine}
All runtime configuration is done with \texttt{fiji\} or \texttt{fiji\_ee\}
which communicate with the DUT over a common serial connection. It works with
any type of serial port (e.g. RS-232-compatible ports or USB-based TTL-level
adapters) as long as the operating system represents it as such. The scripts
support three modes:
\item Interactive: The user is asked interactively for the various items needed
to build a valid configuration message for the current design.
If available (e.g. via the \ac{FIJI} Settings) it offers useful
default values (e.g. for the design ID). After all information
is typed in the configuration is sent to the device. The respective
responses are received and handled before the user is offered to define another round of parameters.
\item Sequence: \todo{command line usage/features and/or batch configuration file etc.}
\item Random: \todo{command line usage/features and/or batch configuration file etc.}
\subsection{Specification of \ac{FIJI} Settings}
The \ac{FIJI} Settings are organized in blocks of key-value pairs represented
in the same format as common .ini files:
\item Each block starts with the name of the block in square brackets;
\item the key-value pairs that belong to a block follow one per line;
\item the keys on the left side are separated by (the first) equal sign (=) from the values on the right side.
There are two major types of blocks allowed:
\item a single \texttt{consts} block specifies various constants for a specific design.
\item for every \ac{FIU} in the setup there is a respective block named \texttt{FIU\textit{<number>}} where \textit{<number>}
is a strictly increasing integer starting with 0 for the first \ac{FIU} in a design.
Table~\ref{tab:consts} lists all specifiable constants for a design, while
Table~\ref{tab:fiuconsts} explains the settings for each \ac{FIU}. The ``Name''
columns denote the key names in the \ac{FIJI} Settings file. The possible ranges of values and their defaults
are given in the ``Range'' and ``Default'' columns respectively.
The defaults are offered to the user as preselected values and assumed
by the tools if no value is available when one is needed but not available.
\caption{Design Constants}
\caption{FIU Constants}
\caption{Fault Model Type Literals}
%Silence bibtex error \cite{adams2007hitchhiker}
\ No newline at end of file
%Silence bibtex error \cite{adams2007hitchhiker}
This chapter sums up the most important facts related to the scripts used
in the framework (e.g. to instrument the user design and communicate with the
DUT). Their use in the complete tool flow and the respective interfaces
to the vendor tools are described in detail in Chapter~\ref{sec:flow}.
\subsection{Required Modules}
Most of the FIJI software consists of Perl scripts and relies on a number
of libraries that need to be obtained separately to the base installation
of the Perl interpreter. These required Perl packages are listed in Table~\ref{tab:perlmod}.
\caption{Required Perl Modules}
FIJI comes with two scripts for Microsoft Windows and Unix respectively
that install these packages automatically via CPAN. However, this
requires a working C compiler setup on the host (see script files
for details) and installing them by other means (e.g. the package
manager of the Perl distribution) might be preferable.
Besides the information within this file some documentation can be
generated with Doxygen from comments in the source code by executing
``doxygen Doxyfile''. For this to work Doxygen and the filter package
mentioned in Table~\ref{tab:perlmod} need to be installed. By default
only HTML output is created as specified in the configuration file Doxyfile.
\subsection{Execution engine}
The communication with the instrumented DUT is handled by \texttt{fiji\}
and \texttt{fiji\_ee\}. Preferences that are not related to the hardware
are read from its own configuration file named fiji.tst It gathers
the necessary information about the respective hardware design from the
FIJI Settings as described above.
\item input/config files
\item interactive interface
\ No newline at end of file
%Silence bibtex error \cite{adams2007hitchhiker}
A detailed block diagram of the fault injection hardware is shown in Figure~\ref{fig:hardwareblockd}.
It can be seen that all fault injection logic is contained in the top level design unit fault\_injection\_top.
This module is described further in Section~\ref{sec:hw_fi_top}
\caption{Hardware Block Diagram}
\ No newline at end of file
\subsection{Top Level}
This module contains all other fault injection logic such as the fault
injection UART (see Section~\ref{sec:hw_fi_uart}), the \ac{FIC} (see Section~\ref{sec:hw_fic}),
and the fault injection units (see Section~\ref{sec:hw_fiu}).
The fault\_injection\_top module is intended to be configured and instantiated
by \texttt{fiji\} when generating the wrapper module for the modified
netlist. This configuration is done by assigning the desired values to
the constants located in public\_config\_pkg as described in Table~\ref{tab:public_params}.
Both the number of fault injection units and their configuration are
passed in c\_fiu\_config whose type t\_fiu\_records is an array of t\_single\_fiu\_record
defined in the VHDL package public\_config\_pkg.vhd. The described fault
injection units are daisy-chained by their data input and output in the
fault\_injection\_top entity. The leftmost record in c\_fiu\_config describes
FIU 0 (the FIU whose data input is directly connected to the FIC) and
the rightmost describes FIU n-1 (the last FIU in the daisy chain). The
inputs and outputs to be connected at instantiation by the wrapper
are described in Table~\ref{tab:fiu1} and Table\ref{tab:fiu2}, respectively.
The \ac{FIC} decodes the fault injection requests sent by \texttt{fiji\}
or \texttt{fiji\_ee\} and sequences the fault injection process accordingly.
For this purpose it contains:
\item a central state machine
\item the duration counter,
\item CRC calculation logic
\item the LFSR,
\item synchronization and edge detection logic for the trigger signals,
\item registers for the received ID, timer values, and controller configuration.
The central state machine schedules all fault injection operations. This happens
according to the configuration word appended to each configuration message.
The configuration bits specify if the DUT is reset after the configuration
was received, if the FIC waits for the selected trigger signal to transition
from inactive to active (cf. c\_trigger\_dut\_active and c\_trigger\_ext\_active
in Table 6) and which trigger (internal or external) to use.
The LFSR is implemented as a left-shifted Galois type. Thus, the rightmost
bit in the polynomial specified in c\_lfsr\_seed as a global configuration
constant corresponds to $x^1$ and the leftmost bit to $x^{\text{c\_lfsr\_width}}$.
The fault injection units facilitate the actual fault injection.
They are instantiated and configured by fault\_injection\_top. If the
resources and timing slack are available, all possible fault models can
be implemented in a fault injection unit for run-time configuration and
selection. If, however, area or timing is critical, fault injection units
can be configured to implement only one fault model each.
Fault injection units are daisy-chained in fault\_injection\_top as described in Section~\ref{sec:hw_fi_top}.
\caption{Design Constants}
\caption{Toplevel VHDL Inputs}
\caption{Toplevel VHDL Outputs}
......@@ -23,7 +23,9 @@
% Use more powerful glossaries instead of acronym (requires a "makeglossary") %
......@@ -189,14 +191,16 @@
\usepackage{lmodern} % Latin Modern font
\tikzstyle{phase}=[rectangle,draw=black,anchor=east,node distance=2.5cm,minimum width=2.7cm]
\tikzstyle{txt}=[rectangle,anchor=south,text width=2cm,text centered,node distance=1cm,font=\fontsize{8}{8}\selectfont]
\tikzstyle{line} = [draw, thick, -latex']
\node [phase,dashed,fill=orange!20] (conf) {CONF};
\node [txt,above of=conf] () {Receive\\Configuration};
\node [phase,dashed,fill=blue!20,right of=conf] (wt) {WAIT};
\node [txt,above of=wt] () {Wait for Trigger};
\node [phase,dashed,fill=red!20,right of=wt] (re) {RESET};
\node [txt,above of=re] () {Optional\\Reset};
\node [phase,fill=green!20,right of=re] (count) {COUNT};
\node [txt,above of=count] () {Count down timer};
\node [phase,fill=violet!20,right of=count] (fault1) {FAULT1};
\node [txt,above of=fault1] () {Inject Fault 1};
\node [phase,fill=yellow!20,right of=fault1] (fault2) {FAULT2};
\node [txt,above of=fault2] () {Inject Fault 2};
\path [line] ($(conf.north west)$) -- ($(fault2.north east) + (1,0)$);
\path [draw] ($(conf.north west)$) -- ($(conf.north west) + (0,0.5)$);
\path [draw] ($(wt.north west)$) -- ($(wt.north west) + (0,0.5)$);
\path [draw] ($(re.north west)$) -- ($(re.north west) + (0,0.5)$);
\path [draw] ($(count.north west)$) -- ($(count.north west) + (0,0.5)$);
\path [draw] ($(fault1.north west)$) -- ($(fault1.north west) + (0,0.5)$);
\path [draw] ($(fault2.north west)$) -- ($(fault2.north west) + (0,0.5)$);
% thank you
\inheritsavedanchors[from=rectangle] % this is nearly a rectangle
% ... and possibly more
\backgroundpath{% this is new
% store lower right in xa/ya and upper right in xb/yb
\southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
\northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
% compute corner of ‘‘flipped page’’
\pgf@xc=\pgf@xb \advance\pgf@xc by-5pt % this should be a parameter
\pgf@yc=\pgf@yb \advance\pgf@yc by-5pt
% construct main path
% add little corner
\inheritsavedanchors[from=rectangle] % this is nearly a rectangle
% ... and possibly more
\backgroundpath{% this is new
% store lower right in xa/ya and upper right in xb/yb
\southwest \pgf@xa=\pgf@x \pgf@ya=\pgf@y
\northeast \pgf@xb=\pgf@x \pgf@yb=\pgf@y
% compute corner of ‘‘flipped page’’
\pgf@xc=\pgf@xb \advance\pgf@xc by-5pt % this should be a parameter
\pgf@yc=\pgf@yb \advance\pgf@yc by-5pt
% construct main path
% add little corner
\begin{tikzpicture}[node distance = 2.5cm, auto, scale=0.53, every node/.style={transform shape}]
% Define block styles
\tikzstyle{block} = [rectangle, draw, fill=blue!20,
text width=6em, text centered, minimum height=2em] % rounded corners,
\tikzstyle{ourtool} = [rectangle, draw, fill=red!20,
text centered, rounded corners, minimum height=2em]
\tikzstyle{document} = [doc, draw, fill=yellow!20,
text width=6em, text centered, minimum height=2em]
\tikzstyle{line} = [draw, -latex']
\tikzstyle{userdoc} = [document,thick,draw=red]
\tikzstyle{userproc} = [block,thick,draw=red]
% Draw background
\path [draw,dotted] (-2,2) -- (-2,-12);
\path [draw,dotted] (3.5,2) -- (3.5,-12);
\node [anchor=north] at (0.75,1.75) (text_synth1) {\Large Synthesis I};
\path [draw,dotted] (7.5,2) -- (7.5,-12);
\node [anchor=north] at (5.5,1.75) (text_setup) {\Large Setup};
\path [draw,dotted] (13.7,2) -- (13.7,-12);
\node [anchor=north] at (10.7,1.75) (text_instrument) {\Large Instrument};
\path [draw,dotted] (19.25,2) -- (19.25,-12);
\node [anchor=north] at (16.35,1.75) (text_synth2) {\Large Synthesis II};
\path [draw,dotted] (30,2) -- (30,-12);
\node [anchor=north] at (24.5,1.75) (text_inject) {\Large Inject};
% Place nodes
\node [userdoc] (synthconst) {Synthesis\\Constraints};
\node [userdoc, below of=synthconst] (orighdl) {Original\\HDL};
\node [block, below right of=orighdl,node distance=2.7cm] (synth1) {Synthesis Tool};
\node [document, below of=synth1] (orignetlist) {Original\\Netlist};
\node [ourtool, right of=synth1, node distance = 4cm] (setup) {\texttt{fiji\}};
\node [userdoc, above of=setup] (fireq) {FI\\Requirements};
\node [document, below of=setup] (ocfg) {FI\\Configuration};
\node [ourtool, right of=setup, node distance = 4cm] (instrument) {\texttt{fiji\}};
\node [document, below right of=instrument, node distance = 3cm] (vhdl) {VHDL\\Wrapper \& Config};
\node [document, below of=vhdl, node distance = 2cm] (modnetlist) {Modified\\Netlist};
\node [document, below of=modnetlist, node distance = 2cm] (icfg) {FI\\Configuration\\with ID};
\node [block, right of=instrument, node distance = 6cm] (synth2) {Synthesis Tool};
\node [userproc, above of=synth2, node distance = 3.2cm] (adapt) {Adapt};
\node [document, above right of=synth2] (fijihdl) {FIJI HDL};
\node [userdoc, below right of=synth2] (pnrconst) {P \& R Constraints};
\node [block, below of=synth2, node distance = 3.2cm] (pnr) {P \& R Tool};
\node [document, below of=pnr, node distance = 1.5 cm] (bit) {Bitstream};
\node [right of=synth2, node distance = 7.2cm,rotate=45,shift={(0 cm,-3 cm)}] (fpga) {\includegraphics[width=0.15\textwidth]{../tex_common/img/tqfp32.pdf}};
\node [above of=fpga, node distance = 0,] {\textcolor{white}{\textbf{FPGA}}};
\node [above of=fpga, node distance=4cm] (inv) {};
\node [above of=fpga, node distance=2.5cm] {Serial I/F};
\node [ourtool, left of=inv,node distance=2cm] (dlgui) {\texttt{fiji\_ee\}};
\node [ourtool, right of=inv,node distance=2cm] (dlcli) {\texttt{fiji\}};
\node [userdoc, above left of=dlgui, node distance=3.5cm] (tstconf) {Test\\Configuration};
\node [below of=dlcli, node distance=10.1cm] (inv2) {};
% \path [rectangle,draw,dotted] ($(synthconst.north) + (-2,2)$) -| ($(orignetlist.south) + (2,-7)$) -| ($(synthconst.north) + (-2,2)$);
% Draw edges
\path [line] (synthconst) -| ($ (synth1.north) + (0.33,0) $);
\path [line] (synthconst) -| (adapt);
\path [line] (orighdl) -| ($ (synth1.north) - (0.33,0) $);
\path [line] (synth1) -- (orignetlist);
\path [line] (orignetlist) |- ($(orignetlist)+(2.25,-1)$) |- ($(setup.north)+(-0.33,0.5)$) -- ($(setup.north)+(-0.33,0)$);
\path [line] (orignetlist) |- ($(orignetlist)+(2.25,-1)$) |- ($(fireq.north)+(-0.33,0.5)$) -| ($(instrument.north)+(0.33,0)$);
\path [line] (fireq) -- (setup);
\path [line] (setup) -- (ocfg);
\path [line] (ocfg) |- ($(ocfg)+(1.75,-1)$) |- ($(instrument.north)+(-0.33,0.5)$) -| ($(instrument.north)-(0.33,0)$);
\path [line] ($(instrument.south)+(0.25,0)$) |- (vhdl.west);
\path [line] ($(instrument.south)$) |- (modnetlist.west);