@@ -8,31 +8,34 @@ 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.
\Cref{fig:fi_seq} 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).
\fixme{move the whole section to the user manual? without knowing how tests are executed a user cannot configure tests appropriately}
\begin{figure}[ht]
\centering
...
...
@@ -9,40 +10,46 @@
\end{figure}
In Figure~\ref{fig:seq} an extract of a longer execution is depicted showing
In \Cref{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
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 FIC reports the result back to the host. To
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
Section~\ref{sec:f2h}).
\Cref{sec:f2h}).
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
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 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
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 FIC instructs the FIUs to apply fault pattern 2. This pattern
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 FIC notifies the host by sending
\textit{UNDERRUN}. It then waits for a new configuration to be downloaded.
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:
