Commit 7fa9c77e authored by Christian Fibich's avatar Christian Fibich Committed by Stefan Tauner
Browse files

Extended TRM

parent e389470a
......@@ -7,8 +7,31 @@ Silence bibtex error \cite{adams2007hitchhiker}
\caption{FIJI Overview}
\caption{Fault Sequencing}
\ No newline at end of file
\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
the arrival of configuration data from the host, a timer and a trigger signal.
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
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.
At the begin of the second phase (\textit{WAIT}) the FIC resets the 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 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
and thus starts \textit{FAULT2}. This pattern remains active until the next
configuration is received and activated.
The communication between the hardware and fiji\ uses a
UART protocol with 8N1 configuration (8 data bits, 1 stop bit, no parity).
Each communication direction uses its own message format.
\subsection{FIC to Host}
%Silence bibtex error \cite{adams2007hitchhiker}
\ No newline at end of file
The data sent by the FIC to the host serves to inform the host about important events and errors on the hardware side.
\caption{FIC to host communication message format}
There is a single type of packet that consists of a single byte as depicted in Figure~\ref{fig:f2h}.
Bit 8 is used as even parity bit (i.e., it needs to be set iff an uneven
number of remaining bits are set).
Bits 5 and 6 encode message types that inform the host about events that
can happen at the transition between two execution phases:
\item At the end of the configuration phase the FIC acknowledges the
successful reception of the configuration data by sending a
\textit{CONF\_DONE} message with all error bits set to zero.
If there were any of the noted errors while the configuration
was received the respective bits are set and the host is consequently informed about the issues.
\item When the injection of \textit{FAULT1} starts, the temporary registers
storing the configuration are freed and can be filled again
by the host. At that point the FIC sends a \textit{READY} message
to inform the host that injection has been activated and that
a new configuration can be received by the FIC.
\item If the injection phase \textit{FAULT1} ends before the host
has sent a new configuration, the FIC indicates this case with
an \textit{UNDERRUN} message. In this case the exact timing
of later injections depend on the point in time when the
following configuration is received.
Bits 3 and 4 contain the status of the two selected fault detection nets in the instrumented netlist.
This information can, for example, be used to stop a test run when the hardware detected a fault.
The lowest three bits denote possible errors when receiving configuration data from the host:
\item UART receive error
\item Design ID mismatch
\item CRC mismatch
They are only guaranteed to be valid in \textit{CONF\_DONE} messages as noted above.
\subsection{Host to FIC}
The packets sent by the host are more complex. They can be separated into
two major parts: configuration data for the FIUs and information destined
for the FIC itself.
First, the configuration bits for the FIUs are transmitted in a serialized
fashion: To end the actual data at a byte boundary the first bits are used
as stuffing, if need be. Then the data for the last FIU follows succeeded
by the configuration for the FIU before the last etc. At byte borders the
data of a single FIU is simply split and continued to be transmitted in
the next byte. Each 6-bit FIU configuration consists of two 3-bit fault
patterns, of which the pattern transferred first (1) is activated in phase
\textit{FAULT1}, while the second pattern (2) is activated in \textit{FAULT2}.
Each bit pattern is transferred with the least significant bit first.
The remaining part of the message contains control information destined
to the FIC itself. All multi-byte values are transmitted in little-endian
(on the byte and bit level). At first, the load values of the two
timers for the FAULT phases (duration $t_1$ for \textit{FAULT1} and duration $t_2$
for \textit{FAULT2} respectively) are transmitted. The number of bytes
required depends on the width of the timers and can vary between designs.
Following the timer values a bit field is sent to control the following properties:
\item Bit 0 (TE) indicates if the FIC should stay in the \textit{WAIT} phase until the trigger is detected.
\item Bit 1 (XT) decides the trigger’s source: either the external trigger input, or the internal trigger from the DUT.
\item Bit 2 (R) specifies if the user design should be reset by the FIC at the beginning of the \textit{WAIT} phase.
\item Bit 7 (U) specifies that the current configuration shall not be activated. This can be used to retrieve
the state of the Fault Detect signals without interrupting an active \textit{FAULT2} pattern.
Then, the 16 bits of the design ID is transmitted to allow the FIC to
check the sent configuration for compatibility.
An 8-bit CRC at the end protects the message against bit flips.
The polynomial used is 0xE0 with an initialization value of 0xFF.
The data for the CRC algorithm is input and output as big-endian.
\caption{Host to FIC communication message format}
\section{Execution Flow}
%Silence bibtex error \cite{adams2007hitchhiker}
\caption{Fault Sequencing}
In Figure~\ref{fig:seq} an extract of a longer execution is depicted showing
some of the possible sequences of events.
First of all, the FIC must acquire a valid configuration consisting of the
packets explained above. If there are any reception errors (frame error, wrong
ID, or CRC mismatch) the 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 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
Upon the successful reception of a configuration, the DUT is reset by the FIC
if requested. The FIC then optionally waits for a trigger signal (again
depending on a configuration setting) and then starts the next phase. The
second and partially visible third execution cycles 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 FIC instructs the FIUs to apply fault pattern 1 and thus possibly enables
the forwarding of faulty signals by the FIUs. At this point the 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 FIC instructs the FIUs to apply fault pattern 2. This pattern
stays active until the duration $t_1$ of the next configuration has been counted
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 FIC notifies the host by sending
\textit{UNDERRUN}. It then waits for a new configuration to be downloaded.
\section{Tool Flow and Settings}
\ No newline at end of file
\section{Current Limitations}
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:
\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
any errors caused by fault injection in the DUT}
\item \todo{TBC?}
\ No newline at end of file
......@@ -254,8 +254,11 @@
%%%%% MAIN CONTENT %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
......@@ -10,15 +10,13 @@ which can be found in Table~\ref{tab:perlmod}.
Category & OS & Name & Version \\
Perl Interpreter & Unix/Linux & Perl & v5.22.1 \\
& Windows & Strawberry Perl & v5.16.3 \\
FPGA Synthesis Tool & Unix/Linux, Windows & Synopsys Synplify & I-2013.09-SP1 \\
FPGA Implementation Tool & Unix/Linux, Windows & Altera Quartus II & 13.0 \\
& Unix/Linux, Windows & Xilinx ISE & \todo{Test} \\
Category & OS & Name & Version \\ \hline
Perl Interpreter & Unix/Linux & Perl & v5.22.1 \\
& Windows & Strawberry Perl & v5.16.3 \\
FPGA Synthesis Tool & Unix/Linux, Windows & Synopsys Synplify & I-2013.09-SP1 \\
FPGA Implementation Tool & Unix/Linux, Windows & Altera Quartus II & 13.0 \\
& Unix/Linux, Windows & Xilinx Vivado & \todo{Test} \\ \hline
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment