A verification engineer flips one bit near the result register after a failed signature check. No CPU fetch appears, so the report says the fault was blocked. The designer notices that the disturbance ended before the request. Did a defense work, or did the fault miss its opportunity?
Changing stored state instead can leave the error in place until a request arrives. Both tests are called bit flips, but they differ in target, timing and recovery. The name alone does not describe the experiment.
This lesson turns those conditions into a reproducible experiment contract. You will identify what an injector changes and what a trace without unauthorized acceptance actually establishes. A clear model lets someone else rerun and challenge the result.
Start with Lesson 1: why correct RTL can still be unsafe. Allow about 35–45 minutes. The examples use synchronous registers and a simplified valid/ready interface. The circuits, injector and Python exercise are original two-state teaching models. The completed checks are Python enumeration and website acceptance; RTL simulation, synthesis, formal proof and silicon fault testing have not been performed.
1. One bit flip, different outcomes
Think of the whole lesson as a school’s homework-check stamps. A student may collect today’s exam paper only after the record says both check complete and homework passed. This homework is wrong, so the fair teacher’s original decision remains fail. The attempt starts at period 0; checking finishes at period 2; the student visits the door at periods 4 and 6. Period N stands for discrete edge N, not a real class period lasting one hardware clock cycle.
Ask three questions before calling anything a bit flip: which record changes, how long does it change, and does the door see it when the student arrives? In A, a finger hides the saved fail mark at period 3 and briefly makes it look like pass. Removing the finger leaves fail intact, so period 4 sees no illusion. In B, someone changes the saved mark to pass at period 3 and leaves it there. Both visits succeed: one alteration, two consequences. In C, someone swaps the decision being handed over at period 2 while it is being recorded. The wrong decision stays in the record. The same swap at period 3 has no effect because recording has closed. In D, the record stays fail, but the final door permission is changed at period 4. D expands the final-grant fault boundary; it is a separate experiment from A–C.
Keep the teacher’s original decision separate from the saved grade. C changes the signal delivered to storage, not the independent answer as well. D changes the last permission decision; the request and acceptance mechanism still follow the rules.
Keep the fictional boot path from Lesson 1. checked_q records completion and result_q stores whether verification passed. Both must be high for permission. Instruction fetch means reading a program instruction. We observe accepted_commit at the simplified fetch interface, rather than treating it as CPU retirement or the complete execution event.
Fix the schedule: reset at edge 0, verification completes at edge 2, and valid, ready requests occur at edges 4 and 6. The image is unauthorized, so the fault-free stored result stays 0.
Invert only the observed Q at edge 3 and remove the disturbance before edge 4: the consumer sees no error at acceptance. Change the stored Q after edge 3’s update instead, with no later overwrite: the error survives into edge 4. The difference is storage and duration. The checker can remain correct throughout.
Predict what the consumer reads before inspecting the program. You need both the request schedule and the error’s retention rule. Knowing only that a flip occurred cannot determine what the accepting interface sees.
2. Write a model card another engineer can run
Write school rules that another teacher could reproduce. Wrong homework must not lead to an exam paper. From period 0 through period 7, allow at most one action, at one location, on one target bit. Visits at 4 and 6 share that opportunity. The assignment and original grade, the clock, completion signal, non-target fields, and acceptance mechanism are trusted for this experiment. That is an analysis premise, not a claim that they cannot be attacked.
| School role or record | Hardware counterpart | Distinction to retain |
|---|---|---|
| Fixed homework with wrong answers | Fixed unauthorized image | The assignment is not a fault target |
| Teacher’s original decision and the decision handed over | Normal auth_ok_i and injected auth_seen | C changes the delivered value; the independent reference remains unchanged |
| Saved grade field or pass mark | result_q | B changes storage; A changes only result_seen at the reader |
| Completed-registration mark | checked_q | Complete does not mean pass |
| Completion notice at period 2 | verify_done_i | It enables write_en; it is not the grade |
| Door permission decision | grant_clean / exec_grant_o | A–C trust the final gate; D separately targets final permission |
| Student arrives and the door can receive the request | fetch_valid_i / fetch_ready_i | Neither is a fault budget or grade |
| Record of receiving the exam paper | accepted_commit | Request, ready, and grant must coincide |
| Independent grade and completion ledger | ref_auth_pass / ref_auth_complete | A testbench reference, never copied from the altered record |
The grade sheet represents DUT storage. The independent ledger represents the reference. The analogy does not add a teacher or a new defense inside the chip.
The model card is a handoff document. Another engineer should be able to configure the injector and monitor from it and identify an authorization failure. Begin with case B: change stored result state once after failed verification. Keep distinct locations separate rather than labeling everything “a single-bit attack.”
| Field | Explicit setting for case B |
|---|---|
| Asset and failure event | An unauthorized image must receive no accepted_commit |
| Initial state and workload | Reset at 0; fixed unauthorized image; completion at 2; requests at 4 and 6 |
| Target and abstraction | One-bit result_q stored state; RTL state-transition model |
| Effect and recovery | One inversion, retained until overwrite/reset; no continuously forced drive |
| Timing and order | Chosen edge 2..7: sample acceptance, perform normal update, then change new state |
| Budget and units | At most 1 event, 1 location and 1 target bit per reset-to-edge-7 boot attempt |
| Trusted/excluded boundary | Image/policy, independent reference, clock/reset, verify_done, checked_q, non-target logic, handshake/acceptance and injector |
| Observation window | Edges 0..7 inclusive; both requests share one attempt and budget |
| Outcome and evidence | Record raw Q, observed value, grant, commit and reference; no detector is implemented |
These capabilities were selected for a bounded question, not measured from a product. Clock, reset and checker attacks require new models; this card does not protect those excluded targets.
Give the reviewer the trust assumptions too. A trusted reference lets the experiment identify a wrong DUT decision; trusted acceptance logic lets it record commit as specified. Faulting those elements requires a revised experiment, not just another name in the target list.
SYNFI describes spatial and temporal fault properties through location, duration and time, and configures experiments with locations, effects and simultaneous-fault counts. We use that discipline without running SYNFI. Author paper, Sections 2.1 and 3.1
3. Count events, locations and bits separately
B alters one pass mark, and both visits produce an exam paper. That still spends one action. Altering it at period 3 and again at period 5 spends two, even at the same location. A single finger held across two sampling edges can represent one two-edge pulse; B’s surviving mark represents a state change’s after-effect. Event count, duration, and acceptance count need separate fields. Reset starts the next experimental budget; this does not bound attempts over a product’s lifetime.
“Only once” needs a unit. One event can affect one location or several bits in a register. Two events can target the same location at different times. These restrictions are not interchangeable.
| Unit | Question to answer | This lesson |
|---|---|---|
| Events | How many injection actions occur? | One event per fault trace |
| Locations | How many distinct targets are affected? | One target per run |
| Target bits | Which bits may change at that target? | One bit; no multi-bit claim |
| Active interval | How many sampled edges can an event affect? | A pulse spans 1 or 2 edges; an upset’s state effect can persist |
| Attempts/reset rule | When does a new budget begin? | A new boot attempt begins after another reset |
A stored upset at edge 3 can affect requests at 4 and 6. That is one event with lasting consequences. Flipping the bit again at edge 5 is a second event, even at the same location, and exceeds this lesson’s budget. Repeated device restarts need another product assumption: we do not bound lifetime attempts.
Two unauthorized acceptances do not imply two injections. Event count describes the attack action; commit count describes its consequences. One retained error can affect several requests, while an event that misses all requests can have no observed consequence.
Tools also use different counting rules. FIRMER separates events per cycle, cycles with events, effect types and logic/memory targets. Its treatment of persistent faults cannot simply be renamed our “one stored-state change with retention.” Align semantics before comparing counts. FIRMER paper, Sections 1 and 3
4. Draw a Q pulse and a stored-state upset
Look at the ink on the grade sheet to distinguish A from B. A changes the reading path: result_seen = result_q XOR fi_q_xor_i. The saved ink stays intact. B acts once but changes the stored mark; later holds read the altered result_q. C swaps the delivered decision while writing is enabled, corresponding to auth_seen. The mark, the obstruction, and the handed-over decision are three different targets. Test them separately rather than changing all three under a one-location claim.
Case A adds an XOR on the observation path: result_seen = result_q ^ fi_q_xor_i. With the control high, the consumer sees the complement. With it low, the consumer sees the original Q again. The XOR does not write the register. Without feedback from that observation into D, this pulse does not change raw result_q.
Case B changes stored state. The teaching RTL expresses that effect with a next-state XOR: select the normal next value, invert it under fi_state_xor_i, then load the DFF. Remove the control on the next edge and the hold path reads back the already corrupted Q, retaining it. This models a state transition in RTL; it does not claim that a particle, laser or EM disturbance physically targets D.
Case C inverts auth_ok_i before capture. A pulse covering completion at edge 2 is stored, so the wrong answer survives after the pulse ends. A pulse covering only edge 3 misses the write, which has already closed. Its target is the upstream decision, separate from cases A and B, with its own trace.
force/release, backdoor deposit and an injection mux are ways to implement injection. Check their actual behavior for the simulator, net/variable and normal update process. An API name alone does not specify every upset. OpenTitan’s countermeasure verification framework also uses selected internal targets to exercise defenses; a project must still align the injection model and observation point. Official framework
5. Which value is sampled at the same edge?
At each bell, the door first uses the already stable record to decide that handover, then registration and any stored-mark alteration finish. B’s change after period 3 affects period 4. A change after period 4 cannot revise a handover already recorded at that edge. This follows sampling commit, normal update, then state upset. People can read and write at overlapping times; the teaching model fixes pre-edge and post-edge order and does not simulate those races or physical gate delays.
Read each rising edge in three steps. Stabilize inputs and pulse controls beforehand. Sample old Q, grant and commit at the edge. Complete the register update afterward. Case B’s state XOR affects the new Q, so it cannot retroactively change the commit already sampled at that edge.
Before edge 2’s update, the trusted reference has ref_auth_complete=0; afterward it becomes 1. verify_done_i remains trusted. Case C corrupts only auth_ok_i. Reference pass comes independently from the fixed image and policy, stays 0 for the unauthorized image, and never copies faulted result_q.
Moving acceptance by one edge or changing a state upset to a pre-edge write can change the counterexample. Driving controls with blocking assignments at posedge can also create a testbench race. Stabilize injection controls before sampling and distinguish pre/post-update observations. The Python model does not simulate event-region races.
Record Q before the edge and after the update separately. A change made after edge 3 can affect acceptance at edge 4; it cannot rewrite the event already recorded at edge 3. The Python model and RTL harness must share that ordering contract.
Compare three effects at the same edge 3
With the action fixed at period 3, A returns to fail when the finger moves, B leaves a changed mark, and C reaches a registration window that has already closed. Only B produces unauthorized acceptance at period 4. Move C to period 2 and the open write window saves the false pass. The homework and door visits stay fixed; only effect or timing changes. A and C do not trigger a detector, so their lack of acceptance cannot be reported as detected or blocked.
“Before” means settled values at sampling; “after” means stored values after the normal update and injection. The image fails. After edge 2, checked=1 and result=0. Requests stay at edges 4 and 6, so this comparison does not change the workload.
| Experiment at edge 3 | What is observed or stored | Grant at edge 4 |
|---|---|---|
| A: Q pulse only at edge 3 | seen=1 but stored Q=0; the pulse then ends | checked AND seen = 1 AND 0 = 0 |
| B: flip stored Q after edge 3 | Q changes from 0 to 1; hold preserves 1 | 1 AND 1 = 1 |
| C: source pulse only at edge 3 | write_en=0; the source is not captured again | 1 AND 0 = 0 |
B can therefore cause unauthorized acceptance at edges 4 and 6 with one injection. A and C do not: this schedule neither preserves nor uses their error. No detector blocked them. Move C to the completion sampling at edge 2 and write_en becomes 1, capturing the wrong source. Predict that row before rerunning the Python trace.
6. Match the effects to RTL, then expand a boundary
When reading RTL, treat write_en as the grade-registration window. fi_source_xor_i swaps the handed-over decision, fi_state_xor_i alters the newly stored mark, and fi_q_xor_i obscures the value seen at the door. D’s fi_grant_xor_i changes final permission directly: the record remains fail but the period-4 visit succeeds. D changes the premise that the final gate is trusted, while valid, ready, and the acceptance mechanism remain outside its target.
At an actual exam-paper handover, an auditor checks independent completion and the original grade, corresponding to ref_auth_complete AND ref_auth_pass checked at the same sampled edge whenever accepted_commit is true. The harness must separately enforce the one-action budget. Writing an SVA rule does not automatically prevent a second alteration.
Download the complete teaching injection wrapper. These fragments belong to one module. With every fi_* at 0, it reproduces Lesson 1’s vulnerable gate. The controls are for experiments and must be kept out of production RTL.
assign write_en = verify_done_i && !checked_q;
assign auth_seen = auth_ok_i ^ fi_source_xor_i;
assign result_d = (write_en ? auth_seen : result_q) ^ fi_state_xor_i;
always_ff @(posedge clk_i or negedge rst_ni) begin
if (!rst_ni) begin
checked_q <= 1'b0;
result_q <= 1'b0;
end else begin
if (write_en) checked_q <= 1'b1;
result_q <= result_d;
end
endfi_source_xor_i changes the decision to be sampled. fi_state_xor_i changes the resulting stored state. The campaign permits one event at one target. Holding state XOR high for two edges flips twice, which is not the single-upset model here.
assign result_seen = result_q ^ fi_q_xor_i;
assign grant_clean = checked_q && result_seen;
assign exec_grant_o = grant_clean ^ fi_grant_xor_i;
assign accepted_commit = fetch_valid_i && fetch_ready_i && exec_grant_o;Cases A, B and C exclude faults in final grant. Case D opens that boundary: fi_grant_xor_i inverts grant, while valid, ready and actual acceptance remain trusted. If the unauthorized image receives grant at edge 4, the consumer can accept it according to its contract. Results for A/B/C cannot establish protection against D.
The security property remains at actual acceptance:
assert property (@(posedge clk_i) disable iff (!rst_ni)
accepted_commit |-> ref_auth_complete && ref_auth_pass);
cover property (@(posedge clk_i) disable iff (!rst_ni)
ref_auth_complete && ref_auth_pass ##[1:8] accepted_commit);These properties await a testbench or formal harness; they have not been compiled or proved. |-> checks the same sampled edge, and disable iff excludes asserted reset. The cover asks for one reachable authorized path, not successful completion of every authorized attempt. Availability needs progress, timeout and recovery requirements. The harness must enforce the fault budget too; an assertion does not create a one-event model by itself.
7. Run 42 cases and read the trace before PASS
Each of the 42 exercises starts again with the same wrong homework. Report the periods when an exam paper was handed over, then identify the record changed. Altering the saved mark after period 3 leaves two handovers; altering it after period 6 leaves none because the original schedule has no later visit through period 7. These are B traces with different starting edges. The latter may still hold a wrong mark: no later visit is not a guard stopping it. The 18/42 count describes this enumeration, not measured real-world success odds.
Download the Python exercise and run Python 3. The output folder preserves every edge’s trace:
python lesson02_fault_model.py --output-dir lesson02-resultsThe campaign enumerates six starting edges (2..7). A/C/D each use 1- or 2-edge pulses; B uses one state-upset event per start, giving 42 fault cases. Each run resets independently and uses the same unauthorized image and request schedule. Two separate fault-free controls show the authorized image accepted at 4 and 6 and the unauthorized image accepted at neither.
| Example | Unauthorized acceptance edges | Interpretation |
|---|---|---|
| A: Q pulse covers only edge 3 | None | No unauthorized commit observed at 0..7; no detector, so no detection claim |
| B: stored upset after edge 3 | 4, 6 | One event affects two acceptance opportunities |
| C: source pulse covers edge 2 | 4, 6 | Completion captures the corrupted decision |
| C: source pulse covers only edge 3 | None | No unauthorized commit observed at 0..7; missing capture is not complete protection |
| D: grant pulse covers edge 4 | 4 | The original result remains failure, but grant changes |
| B: stored upset after edge 6 | None | No later request in the 0..7 schedule; no detector, and later behavior is unknown |
Execution produced 18 cases with unauthorized acceptance and 24 without it in the specified window and schedule. PASS means expected controls and counterexamples were reproduced, including failures of deliberately vulnerable logic. It is not an IP security pass. Nor is 18/42 a physical attack success probability: this enumeration measures no distribution, reachability or perturbation strength.
There is no “detected” column because this lesson adds no detector. For cases without a commit, report the observation, then investigate why. Missing a request, missing the capture edge and having no later request in the window are not active blocking by a defense.
Rerun the final row with requests at 4, 6 and 7. The same upset after edge 6 now causes unauthorized acceptance at 7; the script already checks that changed schedule. The earlier negative outcome belonged to its window and workload. It cannot be renamed “fault blocked.”
8. Connect the experiment to a design and product
To improve the school process, identify the segment exposed by altering the mark, swapping the delivered grade, or changing door permission. A more elaborate grade sheet checks some storage alterations; it does not certify the teacher-to-record handover or final door. These are storage integrity, source binding, and the consumer path. The story separates responsibilities rather than proving that extra marks cover every physical fault.
No defense has been added here. The first improvement is an accurate model and reproducible failure. Then choose measures for the target: stored corruption calls for storage integrity analysis; captured wrong decisions call for producer protection and authorization binding; corrupted grant requires analysis of the consumer and final delivery path. Lesson 3 examines register integrity before later lessons cover multi-bit controls and shared failures.
Record design/model versions, target list, injection parameters, initial state, workload, horizon and counterexample trace. Also record whether injection happened and whether the requested property was evaluated. Tool timeouts, failed injection, disabled assertions and absent requests cannot count as security passes.
Track three questions separately: did injection take effect, did a sensitive request arrive, and was the property evaluated? Missing any one leaves an unresolved item. That record reveals verification gaps that a final PASS line can hide.
For prefetch, DMA, debug or secret-read paths, identify each sensitive acceptance event. Clock/reset attacks and repeated or multi-cycle injections need new effect and trust assumptions plus new controls. Changing the reference to reuse a faulted value only hides the error.
Logical analysis leaves a measurement gap. SYNFI states exclusions for subcycle transients, gate propagation delay and physical layout; this smaller Python exercise cannot answer those questions either. Product use needs post-synthesis target correspondence, physical-effect calibration and evidence that detection/blocking precedes delivery. SYNFI, Section 6
9. Read papers without importing the wrong model
Reading another fault model resembles reading another school’s exercise log. If its one action keeps a mark obscured for a whole interval, while ours lasts one sampling edge, the durations already differ. Testing the final door does not transfer a result to saved grades either. Put target, duration, and acceptance deadline on the same comparison card. This is a reading method; it does not turn this lesson into a SYNFI, VerFI, or FIRMER experiment.
SYNFI is useful for reading a specification: which subcircuit, input/expected output, gate mappings and simultaneous-fault count were chosen? Its netlist preprocessing and time assumptions differ from our edge-by-edge model.
VerFI (IEEE HOST 2020) bounds an adversary model before simulating faults with test vectors. It records undetected locations, effects and cycles. Distinguish faults revealed by test-vector comparisons, alerts from a hardware countermeasure and whether protected output escaped first. The Python exercise does not call VerFI. Author paper, Sections II and III
FIRMER parameterizes events, cycles, effects and target classes. Ask whether one event in that tool means the same thing as one injection in your card. We have not reproduced its benchmarks or SAT proofs. Paper
OpenTitan’s hardware guidelines identify sensitive operations and consequences of corrupting internal nodes or final permission signals. Those questions help populate the card’s protected event and target list; they do not prove this teaching gate secure. Official guidelines
Sources were checked on 2026-10-03. Grok completed independent cited research. Claude’s web search did not complete; it instead reviewed Codex-verified sources and the proposed model, followed by a read-only implementation audit. Codex owns source adjudication, code and deployment. Tool claims remain bounded by their own assumptions.
- Pascal Nasahl et al., SYNFI: Pre-Silicon Fault Analysis of an Open-Source Secure Element, TCHES 2022(4). Author version. Assignment: map simultaneous count, sites and effects to your card.
- Victor Arribas, Felix Wegener, Amir Moradi and Svetla Nikova, Cryptographic Fault Diagnosis using VerFI, IEEE HOST 2020, pp. 229–240. Author paper / Institution record. Assignment: identify the undetected-case fields and add your acceptance event.
- Huiyu Tan et al., SAT-based Formal Verification of Fault Injection Countermeasures for Cryptographic Circuits, TCHES 2024(4). CHES-hosted paper version. Assignment: distinguish events per cycle, injectable cycles and target classes from this exercise’s counts.
- lowRISC, Secure Hardware Design Guidelines and Security Countermeasure Verification Framework. Design / Verification. These live documents change; pin a version for project experiments.
10. Change a request time and rewrite the contract
Change only the itinerary: visit again at period 7. The pass mark altered after period 6 is still there, so that new visit receives an exam paper. The action budget remains one; the new acceptance opportunity is what changed. This corresponds to extraFetch=true and exposes the after-effect without another injection. Allowing two actions would require a separate model card, rather than changing both the itinerary and the budget while claiming a one-condition comparison.
Add edge 7 to the request schedule and predict the 42 cases again. Before changing expected answers, identify which target’s effects remain and which acceptance edge can see them. Then expand the event budget from one to two. Explain why repeat flips at one site and simultaneous faults at different sites need different enumeration.
Finish with a model card and counterexample trace a colleague can rerun without guessing injection semantics. Next comes “Register integrity,” using this contract to compare parity, complementary encoding and ECC. Publication status and lesson order are maintained in the course outline.
MY ACADEMY · LESSON FILM
Lesson video
The film explains this lesson’s data path. After a section, return to the interactive exercise and change the input or fault conditions. The animation presents a teaching model; it does not replace RTL simulation.
Narration uses a synthetic voice. Both the interaction and animation have model boundaries; interpret results using this lesson’s sources and validation scope.
MY ACADEMY · RTL LAB
Operate the fault model: what changed at this edge?
Compare a Q pulse at edge 3 with a state upset. The pulse changes the observed value; the upset changes stored state after the update. Try an upset at edge 6, then add an edge 7 request. The window and request schedule change the result.
Each edge applies pulse controls, samples commit, then updates registers. A state upset occurs after the normal update. The result is captured at edge 2; default requests occur at edges 4 and 6.
Evidence scope: a finite two-state teaching model ported from the existing Python exercise, observing edges 0–7. The independent reference, clock/reset and accepting endpoint remain trusted. No RTL, formal or silicon validation is performed.
Before this edge samples
After this edge updates
Trace (only edges already visited)
| edge | raw Q | seen Q | source | grant | commit | unauthorized |
|---|
No unauthorized commit means none was observed in this window. This model has no detector. Missing a request is not detection or active blocking.
Download the original Python exercise for an independent rerun
Wrap-up: take this lesson into a design review
- Threat model and assumptions
The goal is that a fixed unauthorized image receives no accepted fetch. One reset-to-edge-7 attempt includes both requests at 4 and 6, sharing at most one event at one one-bit location. A changes observed Q, B changes new stored state, C changes auth_ok before completion capture, and D separately includes final grant; each has its own trace.
Image/policy, independent reference, clock/reset, verify_done, checked_q, non-target logic and acceptance remain outside the fault scope. These are experimental trust assumptions, not claims that product targets are immune. Pulse controls stabilize before the edge; acceptance samples old Q, while B changes the new state after update.
- Why the design fails
A bit flip can mean a temporary inversion on a read path or a change to stored state. The former ends when the injector turns off; the latter can survive through hold until a later accepting edge. An upstream error at completion can become the stored result. A corrupted final grant can also release an operation despite a correct upstream answer.
Reports can fail too: a pulse misses a request, no later request occurs in the window, or the property was never evaluated. Renaming such a trace 'detected and blocked' mistakes missing observation for an implemented defense.
- Defenses
First make the failure reproducible with a card specifying target, effect, timing, recovery, counting units, trust and horizon. Then choose defenses for the actual failing stage. Storage integrity, producer authorization binding and consumer permission checks solve different problems.
The XORs and mux are test injectors, not defenses; no detector was added. Keep fi controls out of production and separately verify acceptance deadlines, availability and recovery policy. Lesson 3 begins comparing register countermeasures.
- Validation and checks to perform
Two fault-free controls and 42 Python fault cases ran: 18 had unauthorized acceptance and 24 did not within edges 0..7 and the fixed workload. Checks covered unchanged raw Q under observation pulses, retained state upsets, upstream capture timing, untouched reference and the new counterexample after adding a request at 7. PASS reproduces expected behavior; bypass cases are not security passes.
The RTL wrapper and SVA await a harness; RTL simulation, synthesis and formal proof have not run. Further work must enforce budgets, check effective injection, distinguish pre/post-update sampling and separately report detection, timely blocking and unauthorized commit. Website-diagram acceptance is separate evidence from hardware verification.
- Limits and unverified claims
This finite two-state, discrete-edge model excludes X, metastability, subcycle glitches, gate delays, layout and disturbance probabilities. The 18/42 count is not a silicon attack probability. A window with no unauthorized commit does not establish protection at later times, under other workloads or at other targets.
Clock/reset, common failures, multi-bit/repeated injections, DMA/debug and leakage are outside this campaign. Netlist and silicon work must align targets and physical effects. The per-attempt budget does not bound total device restarts.
Try a changed assumption
Change requests to edges 4, 6 and 7. Predict which effects remain at 7 before rerunning. Then allow two events in one attempt: separately specify repeat flips at one site and simultaneous injections at different sites, and identify the new traces and budget checks.
This wrap-up summarizes the lesson’s teaching cases, references and experiment scope. Checks not reported as completed remain future work.
Learning guide
RTL Anti-Tampering Design
Open the course outline → · Progress counts published lessons only
Prerequisites
- Lesson 1; synchronous registers and valid/ready interfaces
What I learned
- Write a reproducible fault-model card
- Separate transient observations from retained state
- Define sampling order and event-budget units
- Interpret bounded negative results without claiming detection