fabian/fault_injection_async25_paper
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

improved abstract

Browse source
This commit is contained in:
Fabian Posch 2024-12-19 15:22:50 +01:00
parent 3d8cbaadce
commit ec4ed90899
1 changed files with 12 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
fault_injection_async25.tex
View file

@ -55,8 +55,11 @@ rajit.manohar@yale.edu}
\maketitle
\begin{abstract}
ACT is a very versatile and powerful tool for design, simulation and manufacturing of asynchronous circuits. When fault tolerance is a priority, being able to simulate the possible effects as part of the design process can be a huge boon.\\
In this paper we present an augmentation of ACT which allows flexible and comprehensive (transient) fault injection. Key features of this tool are native integration into the existing language framework, distributed computation to speed up wait times, as well as an improved fault distribution model compared to previous attempts. We describe the fault model we targeted, the implementation, issues which had to be overcome, as well as an application example to demonstrate the use and capabilities of the tool.
As a leading toolchain for asynchronous logic development, ACT offers a comprehensive environment for chip design and research. Its open nature allows for extensive customizability, 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, discovering more faults 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}
\begin{IEEEkeywords}
@ -106,7 +109,6 @@ 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}
@ -124,7 +126,7 @@ Points to talk about
\begin{itemize}
\item when does PLF make sense to begin with
\item when does it not make sense
\item why have we not really included it in this analysis
\item (why have we not really included it in this analysis)
\end{itemize}
\subsection{Injection Strategy}
@ -133,6 +135,7 @@ Points to talk about
\begin{itemize}
\item fault distribution: skewed by node fanout instead of average injection density
\item talk about token collector's problem and certainty of coverage, Markov inequality\dots
\item how does runtime scale with circuit size, linear with number of nodes
\end{itemize}
@ -154,6 +157,8 @@ Points to talk about
\begin{itemize}
\item what was the target circuit
\item what metrics did we sweep
\item what was the entire workflow (in case we do two showcases, directly compared to Behal and one for a more full ACT-style workflow)
\end{itemize}
@ -162,9 +167,9 @@ Points to talk about
Points to talk about
\begin{itemize}
\item how many failures were we able to find with our new tool vs with the old tool
\item how efficient (failures found / injection) is this setup compared to previous attempts
\item how do certain families of async and sync compare
\item Compared to Behal: how many failures were we able to find with our new tool vs with the old tool
\item Compared to Behal: how efficient (failures found / injection) is this setup compared to previous attempts
\item Dflow: how do certain families of async and sync compare
\end{itemize}
\section{Conclusion}