In \Cref{fig:seq} an extract of a longer execution is depicted showing
some of the possible sequences of events.
First of all, the \ac{FIC} must acquire a valid configuration as specified in \Cref{sec:h2f}.
If there are any reception errors (frame error, wrong
ID, or CRC mismatch) the \ac{FIC} nevertheless continues reading in the appropriate
amount of frames/bytes for a configuration. Only after the complete reception
of the expected number of bytes the \ac{FIC} reports the result back to the host. To
that end a \textit{CONF\_DONE} message is sent, possibly with some set error bits (see
\Cref{sec:f2h}).
Upon the successful reception of a configuration, the DUT is reset by the \ac{FIC}
if requested. The \ac{FIC} then optionally waits for a trigger signal (again
depending on a configuration setting) and then starts the next phase.
NB: In \Cref{fig:seq} the
second and partially visible third execution cycle do not use any triggers and
thus have no \textit{WAIT} phases at all.
In the \textit{COUNT} phase the timer counts down duration $t_1$. When the timer expires,
the \ac{FIC} instructs the \acp{FIU} to apply fault pattern 1 and thus possibly enables
the forwarding of faulty signals by the \acp{FIU}. At this point the \ac{FIC} reports
back to the host that transmitting a new configuration is now possible with a
\textit{READY} message. Also, it loads the timer with duration $t_2$. When the timer
expires, the \ac{FIC} instructs the \acp{FIU} to apply fault pattern 2. This pattern
stays active until the duration $t_1$ of the next configuration has been counted
down.
In other words $t_1$ determines exactly the time between reception of a new configuration or optionally the arrival of a trigger and the start of the first fault.
$t_2$ on the other hand specifies how long this first fault should be active (before fault~2 becomes active).
In the ideal case the host sends a new configuration while duration $t_2$ of the
previous configuration is still in progress. This allows to apply successive
configurations or even fault patterns themselves without a gap. If the new
configuration does not arrive in time, the \ac{FIC} notifies the host by sending an
\textit{UNDERRUN} message. It then waits for a new configuration to be downloaded.
\subsection{Fault Models}
\fixme{wiederholung von 1. section}
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 (delay fault)
\item Inversion of the original signal for a single clock cycle (\ac{SEU})
\item Pseudo-random data (stuck-open)
\end{itemize}
An overview of the effects of each fault model can be seen in Figure~\ref{fig:faulttiming}.
The \ac{FIJI} framework is highly configurable and consists of various parts that
require access to configuration parameters (see the tables in \Cref{sec:consts} for a complete list).
This chapter sums up some underlying facts of the scripts used in the \ac{FIJI} framework.
Their use in the complete tool flow and the respective interfaces to the vendor tools are described in detail in \Cref{UG:sec:flow} of the \ac{UG}.
\subsection{FIJI Settings}
The \ac{FIJI} framework is highly configurable and consists of various parts that require access to configuration parameters (see the tables in \Cref{sec:settings_consts} for a complete list).
The \ac{FIJI} Settings are organized in blocks of key-value pairs represented in the same format as common \texttt{.ini} files:
\begin{itemize}
\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.
\end{itemize}
There are two major types of blocks allowed:
\begin{itemize}
\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{\ac{FIU}\textit{<number>}} where \textit{<number>}
is a strictly increasing integer starting with 0 for the first \ac{FIU} in a design.
\end{itemize}
\subsection{Constants in \ac{FIJI} Settings}
\label{sec:settings_consts}
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.
\begin{table}
\caption{Design Constants}
\input{content/tab_design_consts.tex}
\label{tab:consts}
\end{table}
\begin{table}
\caption{FIU Constants}
\input{content/tab_fiu_consts.tex}
\label{tab:fiuconsts}
\end{table}
\begin{table}
\caption{Fault Model Type Literals}
\input{content/tab_faultmodels.tex}
\label{tab:faultmodels}
\end{table}
\subsection{FIJI Setup Tool}
The \ac{FIJI} Settings file (usually named \texttt{fiji.cfg}) serves as intermediate
...
...
@@ -54,6 +102,20 @@ Appropriate constraints are added to prevent unwanted optimizations that would i
\subsection{FIJI Execution Engine}
The communication with the instrumented DUT is handled by \texttt{fiji\_ee.pl}
and \texttt{fiji\_ee\_gui.pl}. 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.
\begin{itemize}
\item input/config files
\item interactive interface
\end{itemize}
\todo{Document}
All runtime configuration is done with \texttt{fiji\_ee.pl} or \texttt{fiji\_ee\_gui.pl}
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
...
...
@@ -71,60 +133,27 @@ support three modes:
\item Random: \todo{command line usage/features and/or batch configuration file etc.}
\end{enumerate}
\subsection{Specification of FIJI Settings}
The \ac{FIJI} Settings are organized in blocks of key-value pairs represented
in the same format as common .ini files:
\begin{itemize}
\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.
\end{itemize}
There are two major types of blocks allowed:
\begin{itemize}
\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{\ac{FIU}\textit{<number>}} where \textit{<number>}
is a strictly increasing integer starting with 0 for the first \ac{FIU} in a design.
\end{itemize}
\subsection{Documentation}
\subsubsection{Constants}
\label{sec:consts}
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.
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.
The fault injection system (approach) is designed to be as generic as possible. Nevertheless, it was necessary to impose some limitations, which may be targeted at a later design stage. Currently, the following limitations apply:
\begin{itemize}
\item All nets which are subject to fault injection must reside in
a single clock domain. This is necessary for easier
implementation of the \textit{DELAY}, \textit{SEU}, and \textit{STUCK\_OPEN} fault model,
as these generate their values from synchronous logic in the
fault injection logic. Otherwise, different source clocks
would need to be extracted from the DUT, and extensive synchronization measures would be necessary.
\item Thus, fault injection for nets which reside in a different
clock domain requires re-instrumentation of the FPGA design.
\item Due to the properties inherent to the communication scheme
there might be a large amount of time between the reception
of configurations. Therefore the duration of the second fault
needs to be active for this long time if consecutive configurations
need to be precisely timed (else there would be underflows that break any synchronicity).
\item Due to the encoding of the forwarding/fault type in 3 bits,
another 2 fault types can be added easily. More than the total
of 8 forwarding types would require some hardware and software changes.
\item\todo{Currently, there is no way for the FIJI system to report
