Commit 851729fb authored by Stefan Tauner's avatar Stefan Tauner
Browse files

Restructure and refine TRM and UG

parent c3723ae8
......@@ -34,7 +34,7 @@ use constant FIJI_DOCUMENTATION_PATH => realpath(
File::Spec->catfile(
"..",
"docs",
"userguide",
"user_guide",
"fiji_user_guide.pdf"
),
$FindBin::Bin
......@@ -193,7 +193,7 @@ BEGIN {
phases_opt => [qw(setup instrument download)], # currently not user-configurable at all
},
CFGS_PER_MSG => {
description => "Patterns per FIU configuration",
description => "Patterns sent per FIU configuration",
ini_name => "CFGS_PER_MSG",
default => 2,
type => 'natural',
......@@ -373,7 +373,7 @@ BEGIN {
order => 10,
},
RST_DUT_OUT_NAME => {
description => "Source net for DUT-to-FIJI reset",
description => "Source for DUT-to-FIJI reset",
help => "If enabled, a net in the DUT is used as a reset source for the FIJI logic.",
ini_name => "RST_DUT_OUT_NAME",
depends_on => 'RST_DUT_OUT_EN',
......@@ -384,7 +384,7 @@ BEGIN {
order => 30,
},
RST_DUT_OUT_ACT => {
description => "Active level for DUT-to-FIJI reset",
description => "Active level of DUT-to-FIJI reset",
help => "If enabled, a net in the DUT is used as a reset source for the FIJI logic.",
ini_name => "RST_DUT_OUT_ACT",
type => 'bit',
......@@ -434,7 +434,7 @@ BEGIN {
order => 30,
},
RST_DUT_IN_ACT => {
description => "Active level for FIJI-to-DUT reset",
description => "Active level of FIJI-to-DUT reset",
help => "Enter the level the FIJI-to-DUT reset signal shall be brought to during reset.",
ini_name => "RST_DUT_IN_ACT",
type => 'bit',
......@@ -458,7 +458,7 @@ BEGIN {
},
TRIG_DUT_ACT => {
description => "Active level for DUT-to-FIJI trigger",
description => "Active level of DUT-to-FIJI trigger",
ini_name => "TRIG_DUT_ACT",
help => "Select the signal level to trigger fault injection.",
type => 'bit',
......@@ -493,7 +493,7 @@ BEGIN {
order => 40,
},
TRIG_EXT_ACT => {
description => "Active level for external trigger",
description => "Active level of external trigger",
help => "Select the port level to trigger fault injection.",
ini_name => "TRIG_EXT_ACT",
type => 'bit',
......@@ -600,7 +600,7 @@ BEGIN {
order => 12,
},
OPTIMIZATIONS => {
description => "Optimizations",
description => "Optimization Settings",
help => "Specifies which set of constraints to use in synthesis/P&R to\n- prevent optimizations and/or\n- fix physical placement.",
ini_name => "OPTIMIZATIONS",
type => "dropdown",
......
#!/usr/bin/perl -I../../../bin
use strict;
use warnings;
use Scalar::Util "looks_like_number";
use FIJI qw(:all);
my $map_ref = DESIGNMAP;
foreach my $k (sort(keys(%{$map_ref}))) {
my $values;
# print("$k values ref: " . ref($map_ref->{$k}->{'values'}) . "\n");
my $valref = ref($map_ref->{$k}->{'values'});
if (defined($map_ref->{$k}->{'values'}) && $valref eq "") {
$values = $map_ref->{$k}->{'values'};
} elsif (defined($map_ref->{$k}->{'values'}) && $valref eq "ARRAY") {
$values = join(", ", @{$map_ref->{$k}->{'values'}});
} else {
$values = "";
}
my $default = $map_ref->{$k}->{'default'};
if (!defined($default) || $default eq "") {
$default = "--";
} else {
$default = sprintf("0x%x", $default) if (looks_like_number($default) && $default > 16 && $default < 2**16);
$default =~ s/(.+)/\\texttt{$1}/g;
$default =~ s/\_/\\_/g;
}
my $underscores = ($values =~ s/\_/\\_/g) ? 1 : 0;
my $key = $k =~ s/\_/\\_/gr;
# my @tmp = ($values =~ /([^\s]+\_[^,\s]+)/g);
my @tmp = ($values =~ /([^,\s]+)/g);
if ($underscores) {
$values = '\begin{tabular}[t]{@{}l@{}}' . (join(",\\\\", (map {'\\texttt{' . $_ . '}'} @tmp))) . '\end{tabular}';
# $values = '\begin{tabular}[t]{@{}l@{}}' . (join(", ", (map {print "\$_ = $_\n"} @tmp))) . '\end{tabular}';
} else {
# print "\ninput: $values\n";
$values = (join(", ", (map {'\\texttt{' . $_ . '}'} @tmp)));
}
printf(" \\texttt{%s} & %s & %s & %s \\\\\n", $key, $values, $default, $map_ref->{$k}->{'description'});
}
\section{Foreword}
The target audience of this documents are engineers that want to understand or tinker with the inner workings of the \ac{FIJI} suite.
The technical details contained herein are supposed to be irrelevant to ordinary users.
The reader is expected to be familiar with the goal and application of \ac{FIJI} as explained in the accompanying \hyperref[UG:first_page]{\ac*{UG}}.
\section{Protocol}
\section{Communication Protocol}
The communication between the hardware and the \texttt{fiji\_ee*.pl} tools uses a
UART protocol with 8N1 configuration (8 data bits, 1 stop bit, no parity).
The baud rate is configurable (in \texttt{fiji\_setup.pl}) with a default of 115200.
Each communication direction uses its own message format as explained in the next two subsections.
Each communication direction uses its own message format as explained in the next two sections.
\subsection{FIC to Host}
\label{sec:f2h}
......
\section{Execution Flow}
\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
\includegraphics[width=0.85\linewidth]{img/Pattern.pdf}
\caption{Fault Sequencing}
\label{fig:seq}
\end{figure}
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}.
\begin{figure}[ht]
\centering
\input{img/fault_modes.tex}
\caption{Timing Diagrams for Fault Models}
\label{fig:faulttiming}
\end{figure}
\section{Tool Flow and Settings}
\section{Software}
\label{sec:flow}
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.
\begin{landscape}
\begin{table}
\caption{Design Constants}
\input{content/tab_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}
\pagebreak
\subsection{Testing}
\label{sec:testing}
\end{landscape}
\subsection{\ac{FIC} Emulator}
\label{sec:fic_emulator}
\todo{Document}
\subsection{Instrumentation Tests}
\label{sec:instrumentation_tests}
\todo{Document}
\section{Hardware}
%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.
It can be seen that all fault injection logic is contained in the top level design unit \texttt{fault\_injection\_top}.
This module is described further in Section~\ref{sec:hw_fi_top}
\begin{figure}[ht]
\centering
\includegraphics[width=0.85\linewidth]{img/HW.pdf}
\includegraphics[width=\textwidth]{img/HW.pdf}
\caption{Hardware Block Diagram}
\label{fig:hardwareblockd}
\end{figure}
......@@ -15,19 +14,23 @@ This module is described further in Section~\ref{sec:hw_fi_top}
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
The \texttt{fault\_injection\_top} module is intended to be configured and instantiated
by \texttt{fiji\_instrument.pl} 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}.
the constants located in \texttt{public\_config\_pkg} as described in Table~\ref{tab:vhdl_consts}.
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
passed in \texttt{c\_fiu\_config} whose type \texttt{t\_fiu\_records} is an array of \texttt{t\_single\_fiu\_record}
defined in the VHDL package \texttt{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
\texttt{fault\_injection\_top} entity. The leftmost record in \texttt{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.
are described in \Cref{tab:toplevel_inputs} and \Cref{tab:toplevel_outputs}, respectively.
\subsection{UART}
\label{sec:hw_fi_uart}
\todo{Document}
\subsection{FIC}
\label{sec:hw_fic}
......@@ -35,9 +38,9 @@ The \ac{FIC} decodes the fault injection requests sent by \texttt{fiji\_ee.pl}
or \texttt{fiji\_ee\_gui.pl} and sequences the fault injection process accordingly.
For this purpose it contains:
\begin{itemize}
\item a central state machine
\item a central state machine,
\item the duration counter,
\item CRC calculation logic
\item CRC calculation logic,
\item the \ac{LFSR},
\item synchronization and edge detection logic for the trigger signals,
\item registers for the received ID, timer values, and controller configuration.
......@@ -47,23 +50,26 @@ 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
from inactive to active (cf.\ \texttt{c\_trigger\_dut\_active} and \texttt{c\_trigger\_ext\_active}
in Table 6) and which trigger (internal or external) to use.
The \ac{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}}$.
bit in the polynomial specified in \texttt{c\_lfsr\_seed} as a global configuration
constant corresponds to $x^1$ and the leftmost bit to $x^{\,\texttt{c\_lfsr\_width}}$.
\subsection{FIUs}
\label{sec:hw_fiu}
The fault injection units facilitate the actual fault injection.
They are instantiated and configured by fault\_injection\_top. If the
They are instantiated and configured by \texttt{\texttt{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}.
Fault injection units are daisy-chained in \texttt{\texttt{fault\_injection\_top}} as described in Section~\ref{sec:hw_fi_top}.
\begin{landscape}
\fixme{Add this as footnote to the specification of \texttt{t\_fiu\_records}?
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.}
\begin{table}
\caption{Design Constants}
......@@ -71,6 +77,7 @@ Fault injection units are daisy-chained in fault\_injection\_top as described in
\label{tab:vhdl_consts}
\end{table}
\begin{table}
\caption{Toplevel VHDL Inputs}
\input{content/tab_vhdl_inputs.tex}
......@@ -82,9 +89,3 @@ Fault injection units are daisy-chained in fault\_injection\_top as described in
\input{content/tab_vhdl_outputs.tex}
\label{tab:toplevel_outputs}
\end{table}
\pagebreak
\end{landscape}
\section{Software}
%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}.
\begin{table}
\caption{Required Perl Modules}
\input{content/tab_required_modules.tex}
\label{tab:perlmod}
\end{table}
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.
\subsection{Documentation}
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{fiji\_setup.pl}
\todo{Document}
\subsection{fiji\_instrument.pl}
\todo{Document}
\subsection{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}
\ 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:
\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
any errors caused by fault injection in the DUT}
\item \todo{TBC?}
\end{itemize}
\ No newline at end of file
\begin{tabular}{lllp{25em}}
\toprule
Name & Range & Default & Description\\
\midrule
CLOCK\_NET & String & -- & Name of the clock net in the DUT to be used for clocking the \ac{FIJI} logic\\
FREQUENCY & Design-dependent & 5.00E+07 & Clock frequency of CLOCK\_NET in Hertz\\
BAUDRATE & Host-dependent & 115200 & Baud rate of the serial connection between host and DUT\\
ID & 0 to $2^{16}-1$ & Automatic hash & Design ID\\
TIMER\_WIDTH & 1 to 64 & 32 & Width in bytes of the timer\\
LFSR\_WIDTH & 1 to 64 & 16 & Width in bits of the shared \ac{LFSR}\\
LFSR\_POLY & 0 to $2^{\text{LFSR\_WIDTH}}$-1 & 0x2D & Polynomial specifying the \ac{LFSR} architecture\\
LFSR\_SEED & 0 to $2^{\text{LFSR\_WIDTH}}$-1 & 0xCAFE & Polynomial specifying the \ac{LFSR} architecture\\
FAULT\_DETECT\_INVERT\_MASK & 0 to 3 & 0 & Invert fault detection nets\\
RESET\_EXT\_EN & 0 to 1 & 0 & Enable flag for the external reset input for \ac{FIJI}\\
RESET\_EXT\_ACTIVE & 0 to 1 & -- & Active level of the external reset input\\
RESET\_DUT\_OUT\_EN & 0 to 1 & 0 & Enable flag for the reset from the DUT to \ac{FIJI}\\
RESET\_DUT\_OUT\_NAME & String & -- & Name of the net in the DUT that should drive \ac{FIJI}’s reset (if any)\\
RESET\_DUT\_OUT\_ACTIVE & 0 to 1 & -- & Active level of RESET\_DUT\_OUT\_NAME\\
RESET\_DUT\_IN\_EN & 0 to 1 & 0 & Enable flag for the reset from \ac{FIJI} to the DUT\\
RESET\_DUT\_IN\_NAME & String & -- & Name of the reset net in the DUT to be driven by \ac{FIJI} (if any)\\
RESET\_DUT\_IN\_DURATION & 1 to $2^{32}-1$ & -- & Duration of RESET\_DUT\_IN\_NAME in clock cycles\\
RESET\_DUT\_IN\_ACTIVE & 0 to 1 & -- & Active level of RESET\_DUT\_IN\_NAME\\
TRIGGER\_DUT\_EN & 0 to 1 & 0 & Enable flag for the trigger from the DUT to \ac{FIJI}\\
TRIGGER\_DUT\_NAME & String & -- & Name of the net in the DUT to be used as an internal trigger for \ac{FIJI}\\
TRIGGER\_DUT\_ACTIVE & 0 to 1 & -- & Active level of TRIGGER\_DUT\_NAME\\
TRIGGER\_EXT\_EN & 0 to 1 & 0 & Enable flag for the external trigger input for \ac{FIJI}\\
TRIGGER\_EXT\_ACTIVE & 0 to 1 & -- & Active level of the external trigger input\\
\bottomrule
\end{tabular}
\ No newline at end of file
{\small
\rowcolors{1}{}{tablerowcolor}
% the 0.99 are a hack to stop the rowcolors from bleeding
\begin{tabularx}{0.99\textwidth}{lllX}
\toprule
Name & Range & Default & Description\\
\midline
\texttt{BAUDRATE} & & \texttt{115200} & Baud rate \\
\texttt{CFGS\_PER\_MSG} & & \texttt{2} & Patterns sent per FIU configuration \\
\texttt{CLOCK\_NET} & & -- & Clock net \\
\texttt{FD\_1\_EN} & & \texttt{0} & Enable fault-detect bit 1 \\
\texttt{FD\_1\_INVERT} & \texttt{0}, \texttt{1} & \texttt{0} & Invert fault detect bit 1 \\
\texttt{FD\_1\_NAME} & & -- & Source net for fault-detect bit 1 \\
\texttt{FD\_2\_EN} & & \texttt{0} & Enable fault-detect bit 2 \\
\texttt{FD\_2\_INVERT} & \texttt{0}, \texttt{1} & \texttt{0} & Invert fault detect bit 2 \\
\texttt{FD\_2\_NAME} & & -- & Source net for fault-detect bit 2 \\
\texttt{FIU\_CFG\_BITS} & & \texttt{3} & Bits per FIU pattern \\
\texttt{FIU\_NUM} & & -- & Number of FIUs \\
\texttt{FREQUENCY} & & \texttt{50000000} & Clock frequency \\
\texttt{ID} & & -- & Design ID \\