2026-10-12T17:32:41Z https://www.scidb.cn/oai

10.57760/sciencedb.013jt 2026-09-24T09:42:54Z

2026-09-24 gem5 Simulation CPU Fault Injection Dataset doi:10.57760/sciencedb.013jt en This dataset is designed for the analysis of processor soft errors and fault propagation. It is constructed using the gem5 simulator and contains register-level transient fault injection data collected from AArch64 programs. The experiments use gem5’s MinorCPU model to execute target applications, during which single-bit flip faults are injected into the general-purpose integer registers X0–X30. The dataset records the fault injection time as well as instruction execution and register states within a specified window after fault injection. It can be used to investigate fault propagation behavior, register vulnerability, silent data corruption, and other fault-related phenomena.The experiments are mainly conducted in gem5’s syscall-emulation (SE) mode, and all target applications are compiled as statically linked AArch64 executables. The processor clock frequency is configured to 1.5 GHz, with 32 kB L1 instruction and data caches and a 256 kB L2 cache. The benchmark suite includes a custom matrix computation program and several representative workloads from MiBench, such as basicmath, bitcount, qsort, dijkstra, stringsearch, rijndael, CRC32, and FFT. These workloads cover different application domains, including computation, networking, security, telecommunications, and automotive workloads.For each benchmark, fault injection experiments are independently performed on all 31 general-purpose integer registers from X0 to X30. Each experiment injects a single transient fault into one specified target register. When execution reaches a predefined dynamic instruction position, one bit in the target register is selected and flipped. The bit position is determined by the experiment seed. Multiple independent fault injection runs are performed for each target register by varying the fault injection instruction position and random seed, thereby generating diverse fault samples. The injection intervals are configured according to the dynamic instruction count of each workload; therefore, the range and distribution of fault injection positions may vary across benchmarks.During data processing, the fault injection tick is first extracted from the log file generated for the corresponding simulation run. The processing program then searches the system.cpu.tracer instruction trace for the first instruction record satisfying tracer tick ≥ fault tick, which is regarded as the starting point for fault propagation analysis. By default, 600 consecutive dynamic instructions are extracted starting from this point. The corresponding architectural register states are reconstructed and converted into CSV format. This tick-based alignment approach reduces possible offsets caused by relying solely on dynamic instruction numbers and allows the injected fault to be accurately aligned with subsequent execution states according to gem5 simulation time.The CSV data use dynamic instructions as the basic sampling unit, providing instruction-level temporal resolution. Each row represents one dynamically executed instruction after fault injection together with the corresponding architectural processor state. The main fields include the dynamic instruction number, simulation tick, program counter (PC), and the values of integer registers X0–X30. Some processed files also contain auxiliary information such as the experiment run number, fault injection instruction position, and fault injection tick. Register values are generally stored in hexadecimal format to facilitate bit-level analysis of fault propagation. The exact field definitions are provided in the header of each CSV file.The dataset is organized according to the hierarchy of workload–target register–experiment run. For each workload, the data are divided into two main directories, run and csv. The directories run/X0 through run/X30 contain the gem5 execution logs corresponding to each target register, while csv/X0 through csv/X30 contain the processed instruction-level register-state data.For each experiment, run_i.log stores the gem5 simulation information for the i-th run, including the fault injection position, target register, random seed, fault injection tick, flipped bit, and program execution status. The corresponding main_regs_per_inst_i.csv file contains the fault propagation data extracted from the same run. The log files and CSV files use identical run indices, allowing them to be matched on a one-to-one basis.To reduce memory consumption during large-scale batch processing, the preprocessing program reads the tracer file in a streaming manner and writes the reconstructed register states to CSV incrementally after identifying the required fault injection window. Once the specified number of instructions has been collected, the program stops processing the remaining unrelated trace data. This approach reduces both memory usage and unnecessary processing overhead. The original gem5 execution logs are retained so that the actual fault injection event can be verified and the trace alignment can be reproduced if necessary.Abnormal experiments are explicitly recorded during dataset generation. If a simulation run does not contain an [FI] tick entry, fails to generate a system.cpu.tracer file, terminates abnormally, or exceeds the predefined execution timeout, the corresponding status is recorded in the run log and invalid CSV conversion is skipped. This prevents trace data left over from previous runs from being incorrectly reused. If a fault is injected close to the end of program execution, fewer than 600 instructions may remain, and therefore the corresponding CSV file may contain fewer than 600 records. Consequently, a reduced number of CSV rows does not necessarily indicate data corruption and should be interpreted together with the associated run log. For workloads with verifiable program outputs, the fault-injected result can also be compared with the fault-free reference output to further classify outcomes such as correct execution, silent data corruption, abnormal termination, and timeout.The dataset mainly consists of CSV files and plain-text log files. CSV files can be directly processed using commonly used data-analysis tools such as Python, Pandas, MATLAB, R, and Microsoft Excel. The log files are stored in plain-text format and can be inspected using standard text editors or command-line tools. The dataset can support research on processor reliability, register vulnerability analysis, fault propagation modeling, anomaly detection, and machine-learning-based prediction of soft-error effects. Transient Faults; Fault Injection; Error Propagation; Architectural Registers; Propagation Matrix Prediction He Runze Zhu Xiang RESTRICTED dataset Science Data Bank