final results doc

fault_injection_async25.tex

@@ -229,6 +229,8 @@ However, even if the fault is not masked and affects a primary output in some wa
 In an asynchronous QDI circuits, if a node is already at the forced value but would naturally transition during the fault period; the circuit experiences a temporary slowdown but resumes normal operation afterwards. 
 If this slowdown is visible at an output, we classify the effect as a \emph{timing deviation}. 
 Note that in the context of non-QDI circuits, this is a potential value error.
+
+delay protocol cycle
 % \textcolor{red}{ST: isn't this excluded in the stc above?, yes but I would generally rework this section, because we also have to state that faults are only observed at the primary outputs, otherwise the whole masking makes no sense. -- True!}
 
 All other observable effects are classified according to the following categories.
@@ -382,6 +384,8 @@ In our testing, \texttt{action} has shown itself quite capable as a cluster simu
 
 With respect to the proposed fault-injection setup, one key feature to observe is which number of injections is actually needed to obtain statistically stable results. This can be seen as a measure of how well targeted the parameter selection is.
 
+\textcolor{red}{ST: It would be nice here to have a simulation with all our advanced parameter selection features turned off -- as a baseline to show our merits}
+
 Failure distributions for the examined circuits can be seen in \cref{fig:results/aggregated}. 
 
 \textcolor{red}{ST: do we really have such a low proportion of "nothing"? I can hardly believe that. Same for the high proportion of "timing".}
@@ -390,11 +394,15 @@ The simulation configuration shown in this graph assumed a lower hit-probability
 
 \cref{fig:res/deviation_num_sims_dims,fig:res/deviation_num_sims_nclx} show how observed failure mode distribution changes when the number of injections per signal is decreased. We observe that for both logic styles deviation is less than a single percentage point when going from over 20000 simulations down to about 3000.
 
-\textcolor{red}{ST: Probably more interesting would be a comparison of 4x4 and 8x8 multiplier, as these have}
+\textcolor{red}{ST: Probably more interesting would be a comparison of 4x4 and 8x8 multiplier, as these have largely different node count}
 
 As a similar exercise, we established another baseline test for varying the percentage of signals to be targeted. For this, we configured the injection-engine to select all signals, then gradually lowered the percentage of selected signals (see Figure~\ref{fig:res/deviation_sel_signals_dims} and \ref{fig:res/deviation_sel_signals_nclx}). While not as stable as number of simulations, deviation still stayed within limits down to about 50\%, with the number of glitches observed in \acs{nclx} deviating by about $2.9$ points.
 
-An interesting side note here is that randomness definitely plays a factor here, as a signal coverage of $70\%$ has less deviation from reference for \acs{dims} than $90\%$. Further study would be needed to determine the variance for these values.
+An interesting 
+observation is that
+%side note here is that randomness definitely plays a role, as 
+a signal coverage of $70\%$ has less deviation from reference for \acs{dims} than $90\%$. 
+In the first place this indicates the effect of randomness here, but further study is needed to determine the variance for these values.
 
 Finally, Figure~\ref{fig:res/sim_scaling} shows how the configuration parameters for the injection engine influence the number of calculated required injections. Coverage certainty, hit probability, and victim coverage are in a value range of 0 to 1, while expected failure modes per fanout is in range 1 to 3.\\
 We see that hit probability, victim coverage, as well as expected failure modes change the number of simulations as we expected. While we expected victim coverage to grow the number of injections linearly, this was under the assumptions of all signals having identical fanout. However, since high fanout signals are selected first, we see strong initial growth, which then plateaus out as only low fanout signals are left to be selected.

test-circuit/injection_test.yml

@@ -1,4 +1,3 @@
-
 input_artifacts:
   - name: mult
     type: act
@@ -16,7 +15,7 @@ prepare:
     hit-probability: 0.8
     modes-per-fork: 1
     coverage-certainty: 0.4
-    victim-coverage: 0.05
+    victim-coverage: 0.5
     injection-windows:
       - begin: 240
         end: 1200
@@ -37,3 +36,40 @@ deploy:
 
 # select count (*) from sim_outputs where (fault_flags & B'000001') = B'000001'; select count (*) from sim_outputs where (fault_flags & B'000010') = B'000010'; select count (*) from sim_outputs where (fault_flags & B'000100') = B'000100'; select count (*) from sim_outputs where (fault_flags & B'001000') = B'001000'; select count (*) from sim_outputs where (fault_flags & B'010000') = B'010000'; select count (*) from sim_outputs where (fault_flags & B'100000') = B'100000'; select count (*) from sim_outputs where (fault_flags) = B'000000'; 
 # update sim_configs set part_status = 'not_started' where part_status = 'finished' and not exists (select 1 from sim_outputs so where so.sim_config = sim_configs.id);
+
+
+# input_artifacts:
+#   - name: mult
+#     type: act
+#     source: file
+#     path: testbench.act
+
+# prepare:
+#   - module: testcase_generation
+#     inputs:
+#       design: mult
+#     outputs:
+#       tests: injection_tests
+#     generator: fork_based_set_injection
+#     victim-process: dut.mult
+#     hit-probability: 0.1
+#     modes-per-fork: 1
+#     coverage-certainty: 0.4
+#     victim-coverage: 0.5
+#     injection-windows:
+#       - begin: 1330
+#         end: 11500
+#     injection-duration:
+#       min: 100
+#       max: 400
+#     inject-undefined: false
+#     random-seed: 1234567
+
+# deploy:
+#   - module: actsim
+#     inputs:
+#       design_file: mult
+#       sim_configs: injection_tests
+#     outputs:
+#       sim_outputs: sim_result
+#     top: tb