write introduction, add acronyms

fault_injection_async25.tex

@@ -10,11 +10,20 @@
 \usepackage{textcomp}
 \usepackage{xcolor}
 \usepackage{orcidlink}
+\usepackage[shortcuts,acronym]{glossaries}
+\makeglossaries
+
+% Acronyms for the document
+\newacronym{dut}{DUT}{Design Under Test}
+
+% Simple citation required command
+\newcommand{\citationneeded}{\textcolor{red}{[citation needed]}}
+
 \def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
     T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
 \begin{document}
 
-\title{Conference Paper Title\\
+\title{Lights, camera, \texttt{action}: Towards an efficient tool for fault space exploration\\
 \thanks{Identify applicable funding agency here. If none, delete this.}
 }
 
@@ -56,14 +65,14 @@ NEEDS TO BE CHANGED
 
 \section{Introduction}
 
-Points to talk about
+Exposing digital circuits to environments like space can break some of the most basic assumptions we make when designing digital circuits. Given the level of miniaturization we have access to, having high energy particles rain upon the millions of interconnects in an average design can introduce unexpected behavior. These undesired deviations from design specification, or \emph{failures}, need to be well understood about a design's robustness.
 
-\begin{itemize}
-    \item what is the problem to begin with
-    \item why should one care
-    \item what is temporal masking
-    \item why does async not have this luxury
-\end{itemize}
+Synchronizing logic to a clock cycle, while potentially compromising on average case performance compared to asynchronous logic, has the helpful side-effect of creating a temporal mask for logic faults. This means that when an erroneous value is induced in a wire, only a small window of time exists where this value can propagate beyond the next logic buffer. \\
+In asynchronous logic, we unfortunately lack this convenient abstraction. While we assume temporal masking to also play a much less obvious role in asynchronous logic \citationneeded, environmentally induced faults are still a much higher potential risk compared to a clock synchronized design. 
+
+But what is often much more important than knowing \emph{if} a design can fail under certain (extreme) circumstances, is \emph{how} exactly these failure modes play out. Certain use-cases might call for or even enforce safety in form of known failure modes on systems which are critical given their area of application. While multiple attempts have been made to create tooling for exploration of fault-space in the past \citationneeded, as of yet these tools have several shortcomings we feel need to be addressed. \\
+First, these tools should be natively part of the toolchain slowly emerging as the go-to standard in asynchronous logic design, the ACT suite, published by the Yale AVLSI group \citationneeded. While previous attempts have partially integrated with it \citationneeded, significant progress, such as a new simulator \citationneeded, has been made in the base toolchain. Additionally, the old tool was more of an adapter between ACT and the original workflow \citationneeded, which we feel can be improved. \\
+Second, the previous tool does not account for the potential complexity of knock-on effects a given signal might have in the grander scheme of the \ac{dut}. Average insertion density is used as a stand-in metric to determine whether or not enough tests have been performed. We feel this can be improved upon using a more sophisticated stochastic framework.
 
 \section{Related Work}
 
@@ -97,6 +106,7 @@ Points to talk about
     \item show why this makes sense: only certain input combinations would activate a gate in a way where it could create erroneous output; everything else is logically masked $\rightarrow$ simulation doesn't make sense anyway
     \item which fault scenarios can and cannot be simulated
     \item show some graphs for this
+    \item talk about token collector's problem and certainty of coverage, Markov inequality\dots
 \end{itemize}
 
 \subsection{Types of failure behavior}
@@ -132,7 +142,7 @@ Points to talk about
 
 \begin{itemize}
     \item workflow: setup of harness, similarity to UVM, testbench design intended as design once, use for entire verification workflow
-    \item why is this better than before? Performance improvements, not everything is simulated at gate level anymore, actsim is a mixed level simulator; DUT is simulated at gate level, while harness is simulated at higher level of abstraction
+    \item why is this better than before? Performance improvements, not everything is simulated at gate level anymore, actsim is a mixed level simulator; \acs{dut} is simulated at gate level, while harness is simulated at higher level of abstraction
     \item changes to actsim? Addition of value overriding, addition of delay overriding; Addition of bounded stochastic delay?
     \item Using dflowmap means we can easily target different families of asynchronous circuits and even synchronous circuits and compare
     \item results database and post-processing
@@ -159,6 +169,7 @@ Points to talk about
 
 \section{Conclusion}
 
+\printacronyms
 
 \printbibliography