Definition

A Binary Search Fault-Detected Cycle (BFTC) is the run cycle, expressed in increments of 1024 clock cycles, at which a fault is first detected during the binary-search stage of identifying Fault-Observable Run Cycles (IFTCs) on a target processor. It is defined as the upper-bound cycle of the binary search interval for which the fault remains undetected at the lower bound but is detected at the upper bound. Each BFTC is then refined by an incremental sweep into an exact-cycle Incremental Search Fault-Detected Cycle (IFTC) ^[1].

Generation Procedure

The BFTC is produced as part of the staged Identification of Fault-Observable Run Cycles (IFTCs) process used in the Fault-Run-Cycle-Based FTBE (RCBE) generation flow. The procedure is:

1. Counter baselines. Fault-free node counter values are generated for every node while running the AES binary and stored in 1024-cycle increments from cycle 0 to cycle 6,717,440 ^[1].
2. Binary search. An exponentially increasing multiple of 1024 clock cycles is searched. The search concludes when a multiple of 1024 clock cycles is identified where the fault is undetected at the lower bound and detected at the upper bound ^[1].
3. BFTC storage. The run cycle at which the fault is detected through the binary search is stored as the BFTC ^[1].

Because the search spans 1024 to 6,717,440 clock cycles in 1024-cycle increments, each fault requires 13 iterations of the binary search ^[1].

AES BFTC Values on Potato (1024-cycle resolution)

The table below lists the AES BFTCs observed on the Potato RISC-V core when running the AES binary, tabulated per fault type ^[1].

The highest-latency fault triggered is at cycle 6,078,464, which correlates with delay faults; detecting these delay faults at much lower latencies is identified as a crucial objective of the work ^[1].

Downstream Use

Each BFTC is forwarded into the next pipeline stage, the incremental sweep search, where it acts as the starting value for the single-cycle increment analyses ^[1]:

• The incremental sweep begins at run cycle BFTC − 1024, because the binary search operates at 1024-cycle granularity.
• It iterates at single-clock-period increments, executing both fault-free and faulty tests within a 1024-cycle window.
• The first clock cycle at which counter values differ is recorded as the Incremental Search Fault-Detected Cycle (IFTC), i.e., the exact cycle at which the fault is first observable via node counters.
• A script accepts multiple BFTCs as input arguments and performs the incremental search while iterating through them, automating the process.

The resulting IFTCs are then used to extract the microprocessor (μP) state in simulation and to drive the Binary Creation for Fault-Triggered State Replication step, which assembles a Fault-Run-Cycle-Based FTBE (RCBE) binary that reconstructs register and memory state at the IFTC through LUI/ADDI instructions and memory stores ^[2][1].

Role in the RCBE Flow

The BFTC stage is the first of three colour-coded segments in the RCBE generation flowchart (Figure 5 of the source):

1. Identification of IFTCs (BFTC plus incremental sweep) — yields coarse BFTCs and exact IFTCs.
2. Determination of μP state at the IFTC — a SystemVerilog test bench simulates a clean, non-instrumented Potato to the IFTC, capturing general-purpose register values, the previous 10 instructions, and memory/Wishbone accesses.
3. Binary creation for fault-triggered state replication — assembles a binary that mimics the μP state at the IFTC for use as the RCBE stimulus.

Counter values are extracted from the Potato core by the programmable logic (PL), fault trigger cycles are analysed by the processing system (PS), processor state values are determined by host simulation, and the resulting binary is loaded into the Potato core via the ERSL ^[2].

Distinction from the IFTC

• BFTC: coarse, 1024-cycle-quantized detection point from the binary-search phase; not the exact detection cycle.
• IFTC: exact, single-cycle detection point obtained by refining each BFTC via incremental sweep; used downstream as the simulation stop cycle.

Both terms are introduced and used exclusively within the Fault-Run-Cycle-Based FTBE methodology described in the source paper.