Update on Overleaf.

fault_injection_async25.tex

@@ -24,7 +24,6 @@
 \usetikzlibrary{positioning}
 \usepackage{cleveref}
 
-
 \makeglossaries
 
 % Acronyms for the document
@@ -46,7 +45,6 @@
 \newcommand{\citationneeded}{\textcolor{red}{[citation needed]}}
 \newcommand{\referenceneeded}{\textcolor{red}{[reference needed]}}
 
-
 \makeatletter
 \newcommand{\linebreakand}{%
   \end{@IEEEauthorhalign}
@@ -95,7 +93,7 @@ rajit.manohar@yale.edu}
 \begin{abstract}
 As a leading toolchain for asynchronous logic development, ACT offers a comprehensive environment for chip design and research. Its open nature allows for extensive customization, enabling optimizations beyond what industry-grade tools typically provide. Building on this foundation, we introduce \texttt{action}, a new addition to the ACT toolchain that enables distributed build and compute tasks. To demonstrate its flexible extension interface, we developed a transient-fault-injection engine which significantly improves upon previous designs, both through deeper integration with ACT tools as well as better injection distribution heuristics.
 
-These innovations eliminate the need for additional injection-related logic within the design while also reducing development effort, as testing infrastructure for behavioral validation can simply be reused. Additionally, only the design under test needs simulation at the gate-level, while the auxiliary testing harness can stay at higher levels of abstraction. Finally, we also achieve a reduction in necessary injections by targeting high-fanout signals more heavily, triggering more errors per injection. 
+These innovations eliminate the need for additional injection-related logic within the design while also reducing development effort, as testing infrastructure for behavioral validation can simply be reused. Additionally, only the design under test needs simulation at the gate-level, while the auxiliary testing harness can stay at higher levels of abstraction. Finally, we also achieve a reduction in necessary injections by targeting high-fanout signals more heavily, triggering more failures per injection. 
 
 To validate our setup, we benchmarked it against existing fault-injection tools, demonstrating substantial improvements in both simulation efficiency and the overall number of injections needed to achieve representative results, thus enabling better scaling as target designs grow more complex.
 \end{abstract}
@@ -112,7 +110,7 @@ It is generally agreed that the focus on mainstream synchronous design is one ke
 This lack of \acs{eda} support has somewhat been mitigated by the publication of the open source ACT toolchain by the Yale AVLSI group \cite{manoharOpenSourceDesign}. However, the local compute currently offered by ACT often does not suffice for tasks that are more laborious. 
 
 Especially for those tasks that lend themselves nicely to a high degree of parallelization, cluster computing offers high potential for speed improvements. 
-For this reason, we have augmented ACT with the tool \texttt{action} which does just that - while offering a simple \acs{api} to vastly extend its functionality. Our goal was to create a framework to build on, and we here present a real world use-case to demonstrate this capability.
+For this reason, we have augmented ACT with the tool \texttt{action} which does just that - while offering a simple \acs{api} to largely extend its functionality. Our goal was to create a framework to build on, and we here present a real world use-case to demonstrate this capability.
 
 Specifically, we consider the problem of fault-tolerance assessment through fault injection.
 With applications extending into harsh environments like space on the one hand, and feature sizes in the nanometer regime on the other hand, high-energy particles are getting more likely to cause erroneous behavior of transistors. Consequently fault tolerance is an increasingly desired property of digital circuits, be they synchronous or asynchronous. To this end, studying the behavior of selected target circuits under artificially injected faults is a crucial tool. Beyond a mere quantitative estimation of the error probability of a given design in a given environment, there are also more qualitative, conceptual questions that fault injection can answer. For instance, one may try to understand whether a mechanism like the temporal masking provided by flip flops in synchronous designs also exists in asynchronous designs, established by the communication protocol, and if so, on which parameters it depends.
@@ -139,7 +137,7 @@ This tool has been developed for the \texttt{pypr} toolchain designed by the Hue
 An iteration of this system can be found in \cite{schwendingerEvaluationDifferentTools2022a}. While based on the same core toolflow, Schwendinger adds limited bridging logic to the ACT toolchain, using \textrm{prsim} \cite{manoharOpenSourceDesign} as an alternative simulator. This change requires low level simulation of additional logic, as certain required features were not supported by \texttt{prsim} and no extension to the core simulator code was written. This again is a major point for potential improvement.
 
 Finally, we want to briefly touch on different fault-mitigation techniques seen in literature. \\
-Bainbridge and Salisbury \cite{bainbridgeGlitchSensitivityDefense2009} talk about the basic possibilities for fault behavior in \ac{qdi} circuits. Much like \cite{behalExplainingFaultSensitivity2021}, they identify specific scenarios which can occur when a \ac{set} is injected into a circuit. We will come back to this in Section \ref{sec:system_model/failures} as well. They then lay out basic mitigation techniques, which largely focus on either introducing some form of redundancy in the circuit or reducing the x size of the time window in which faults are converted into failure behavior (sensitivity window).
+Bainbridge and Salisbury \cite{bainbridgeGlitchSensitivityDefense2009} talk about the basic possibilities for fault behavior in \ac{qdi} circuits. Much like \cite{behalExplainingFaultSensitivity2021}, they identify specific scenarios which can occur when a \ac{set} is injected into a circuit. We will come back to this in Section \ref{sec:system_model/failures} as well. They then lay out basic mitigation techniques, which largely focus on either introducing some form of redundancy in the circuit or reducing the size of the time window in which faults are converted into failure behavior (sensitivity window).
 
 In a similar fashion, Huemer et.al \cite{huemerIdentificationConfinementFault2020} present interlocking and deadlocking versions of a \ac{wchb}. These are also meant to reduce the sensitivity window size, as well as preventing the propagation of illegal symbols. We will use their implementations for interlocking and deadlocking \acp{wchb} in this paper (more in Section \ref{sec:experiment_setup}).
 
@@ -244,6 +242,8 @@ All other observable effects are classified according to the following categorie
     \item The transient acts as additional spacing between what is perceived as two data tokens, injecting an additional one into the pipeline. This would also result in a \emph{token count failure} (and potentially a \emph{value failure})
 \end{itemize}
 
+\textcolor{red}{FH: From this explanation it is not clear, if the fault categories are exclusive, e.g., what happens when a fault causes a value error, which then becomes a coding error (because the correct transition happens later) and then the whole circuit deadlocks because of that?}
+
 These failure modes are in accordance with the potential states of a circuit from \cite{bainbridgeGlitchSensitivityDefense2009}; we thus reuse the same failure classification as already presented in \cite{behalExplainingFaultSensitivity2021}.
 
 \subsection{Injection Strategy}