Alerts and local response: did detection arrive before acceptance?

The receiver accepts a bad request at edge 2. Sticky records the error afterward, and the system resets later. The alert works, but it cannot withdraw the accepted request. We put detection and response beside the accepting edge.

Give detection, blocking and recovery separate times

After an equipment-room permission record is corrupted, a student may request equipment. A desk checker detects the problem and refuses handover; an incident log records it; a later school response stops service and clears the room. These are local_bad, sticky, and systemBlock. Wrong permission first appears at f+1, detection is D edges later, and system response another R later. The lab uses systemBlock for the later block and does not model reset sequencing. Bells represent model deadlines, not measured school or chip timing.

A detector identifies an abnormal condition. Local blocking prevents this block from releasing the operation. An alert transports the report to system policy, which might interrupt, wipe or reset. These are different events and can have different latency.

Our storage upset follows edge f. The corrupted permission first appears at edge f+1. Detection appears at f+1+D, where D is an integer delay from zero through four. System blocking starts R further edges later. The chosen request accepts only at its specified edge.

These are teaching edge counts, not OpenTitan measurements. Its alert handler documents escalation as a system mechanism. A product must derive its latency bound from implementation and timing evidence, including the source-to-consumer path. Alert handler documentation

Old sticky cannot reject the first bad edge

At edge 2 the checker already displays refusal, but the old incident log is still clear. Consulting only that log hands over equipment; consulting the current refusal blocks it. If detection arrives at edge 3, even the direct check is too late at edge 2. This distinguishes sticky-only and local. A later alarm or shutdown cannot undo the earlier handover.

At edge 2 with f=1 and D=0, current bad is true but old sticky is false. Local policy requires both current bad and old sticky to be clear, so it blocks. Sticky-only policy reads old sticky and accepts. The sticky register then updates after the already recorded acceptance.

With D=1, even local policy lacks a detection at edge 2. The corrupted grant is already visible, so the request commits before detection at edge 3. Adding a current-error gate helps only after that current error is actually available.

System-only policy waits until f+1+D+R. A later reset may stop additional work and support recovery, but it cannot undo an irreversible delivery. Report first unauthorized acceptance separately from later successful alert propagation.

Expand the first corrupted sampling edge

Fix f=1, D=0, R=2. Permission changes after edge 1; detection is stable before edge 2; the incident log updates after edge 2; the system blocks at edge 4. At edge 2 local refuses while sticky and system can release; at edge 3 sticky refuses but system can release. D=0 assumes detection is stable before sampling, not instantaneous human or hardware response. Moving a request to edge 4 reruns the schedule rather than cancelling edge-2 history.

Fix an unauthorized image, f=1, D=0 and R=2. The storage fault occurs after edge 1. Before edge 2, corrupt=1 and bad=1, but sticky has not captured it. D=0 assumes bad has settled before edge 2 sampling; it does not claim a physical detector has zero propagation delay.

Sampling edge	corrupt	bad	Old sticky	systemBlock	Permission policy
2	1	1	0	0	Local rejects; sticky-only and system can still grant
3	1	1	1	0	Sticky-only rejects; system can still grant
4	1	1	1	1	All three reject

Sticky becomes one only after edge 2 and cannot prevent acceptance already sampled there. System response waits R=2 more edges and blocks at edge 4. Set acceptEdge=2 and compare policies, then set it to 4. Changing acceptEdge reruns a different request schedule; it does not retract an earlier commit.

For persistent corruption, this model's unsafe acceptance windows start at f+1 and end before f+1+D for local, f+2+D for sticky-only, or f+1+D+R for system. The starting edge is included; the blocking endpoint is excluded. With D=0, local's window is empty while sticky-only retains one sampling edge. These results describe the specified discrete schedule, excluding intra-cycle glitches, downstream grant faults and physical gate delays.

State the trusted response boundary

The storage experiment permits one saved-permission alteration while trusting detection, the log, response, and acceptance mechanism. A separate experiment changes final handover permission even when earlier logic refuses: the grant target, not a simultaneous storage fault. Trusting notification links does not verify they cannot fail. The two-state model excludes clock and reset faults, wipe ordering, and actual sensor delays.

The storage campaign has one persistent upset after f in 0..5. D is 0..4, request edge is 0..8, and R=2 in the exhaustive table. The observation ends at edge 8. Sticky starts false. The image reference and all non-target detection/response circuitry remain trusted.

The final-grant experiment is separate: storage remains correct and only grant is inverted at the accepting edge. Earlier local blocking cannot control that downstream force. It does not test faults inside request buffers or the accepting mechanism itself.

Clock/reset faults, alert-link failures, clear/wipe ordering, subcycle pulses and analog sensors lie outside this two-state edge model. A trusted detector is an assumption, not proof that physical detection arrives in time. Real propagation must settle before the accepting edge.

Move one delay and inspect the first commit

Start with a request at edge 2 and immediately available detection. Change only local to sticky to expose first-handover leakage through the old log. Then set D to 1 and even local is late. All three policies should serve an authorized, fault-free student and refuse an unauthorized one. The 810 schedules check these deadlines, not 810 physical attacks. A request before corruption is denied because permission is still false; a request after blocking is denied by the response. Keep those causes separate.

Start with f=1, D=0, request edge 2 and local policy. Step to edge 2: bad is true, sticky false, commit false. Change to sticky policy and export the unauthorized trace. Then return to local and raise D to one. The first request now bypasses even local blocking.

Executed tests swept 810 storage timing traces across six fault edges, five delays, nine request edges and three policies at R=2. A second system-only sweep covered 1,350 traces with R=0..4. Local and sticky policies ignore R. An independent interval assertion checks when acceptance is unsafe; direct edge witnesses anchor that formula. The corrupt flag is a separate timing model, not a detector connected to lessons 4–9.

No-fault authorized controls accept under all three policies. No-fault unauthorized controls reject. A request before corruption has no unauthorized acceptance because the faulty permission is not yet visible; a request after blocking is denied. Those two no-commit causes should have different explanations.

Proposed RTL / SVA

RTL lets current refusal and retained incident history control the desk while the system handles recovery. Separate audit rules require no handover on local_bad and genuine reference_pass for every acceptance. Listing that code does not validate arrival before the accepting edge. The combinational path needs implementation and timing evidence.

Read this lesson's property: Blocking deadlines and acceptance history

If equipment was handed over at edge 2, a closed door and incident mark at edge 4 must not erase that unauthorized event. Keep accepted_commit history and same-edge assertions rather than checking final sticky=1 alone. The first assertion requires no accepted_commit when local_bad is true; the second requires reference_pass whenever acceptance occurs. Cover separately tests an authorized student with an intact record. Those rules and cover do not complete wipe or reset validation.

SVA means SystemVerilog Assertions. An assertion checks a rule; it is not the permission gate. At each rising edge outside reset, if accepted_commit (csr_commit in Lesson 9) is one, |-> requires the right-hand condition on that same edge. With no acceptance, this implication raises no authorization failure; positive controls must still demonstrate useful work. disable iff (!rst_n) excludes active reset, without proving reset safety.

Cover seeks one matching path, rather than proving every transaction correct. Reference independently records the expected result in the testbench. The harness supplies inputs, fault budgets and this oracle; DUT means design under test. A two-state model uses only 0/1 logic, excluding X and intra-cycle delay; it does not mean a two-state FSM. Revisit Lesson 1 section 5 for syntax and wiring comparisons. These snippets have not been compiled, so listing a property does not establish a proof.

always_ff @(posedge clk or negedge rst_n)
  if (!rst_n) sticky_q <= 1'b0;
  else sticky_q <= sticky_q || local_bad;
assign grant = permission_q && !local_bad && !sticky_q;
assign accepted_commit = valid && ready && grant;
assert property (@(posedge clk) disable iff (!rst_n)
  local_bad |-> !accepted_commit);
assert property (@(posedge clk) disable iff (!rst_n)
  accepted_commit |-> reference_pass);
cover property (@(posedge clk) disable iff (!rst_n)
  reference_pass && accepted_commit);

The RTL/SVA sketch is uncompiled. It requires an explicit combinational timing path and trusted final consumer. A system response requirement should separately bound detection-to-alert and alert-to-action, plus verify sustained blocking. Lesson 11 adds reset, clock, CDC and lifecycle boundaries; those subjects remain planned here.

Check your reasoning

Predict collection at edges 2, 3, and 4, then distinguish detection not yet available, an old log, and an active system block. Altering final permission requires a separate target run. The f+1 answer refers to first visible corruption; detection occurs at f+1+D. These questions check ordering among detection, memory, and acceptance. An eventual alarm does not imply no earlier handover.

1. Which value is sticky-only using at the first bad edge?

Old sticky, before its update.

2. When does corruption first appear after f?

At f+1.

3. Can current-error gating block before detection exists?

No.

4. What does the 810 count measure?

Enumerated model traces, not physical success probability.

5. What is outside local blocking when grant itself is forced?

The downstream final permission target.

Engineering wrap-up

The room review needs three records from the same schedule: corruption, available blocking, and actual handover edges. Each item below returns to the first unsafe acceptance deadline. Successful reporting and successful protection do not merge into one PASS, and a familiar alarm does not replace hardware timing validation.

Threat and fault model: One saved-permission alteration persists and is detected at f+1+D. Final permission is a separate target, not a simultaneous storage injection.

One storage upset after edge f; detection f+1+D; request edge 0..8; system response R later. Final-grant forcing runs separately.
Root cause: Equipment can be released before the incident log updates; a later mark cannot undo it. Acceptance precedes blocking even when reporting eventually works.

Detection or old sticky can arrive after irreversible acceptance. A later alert cannot withdraw the delivery.
Defense: Current refusal must arrive before handover; the log retains later blocking and the system handles recovery. D=0 still assumes pre-edge stability, not zero physical delay.

Block with current local detection and remembered history, then define bounded system response and recovery.
Validation: Enumerate 810 schedules at R=2, vary R for the system window, and retain normal collection controls. Counts describe discrete deadlines, not attack success rates.

Node ran 810 three-policy timing traces at R=2, plus 1,350 system traces at R=0..4, interval checks, a grant witness and authorized controls. Timing closure and RTL remain unverified.
Limits: Detection is trusted; broken notification and wipe behavior are excluded. Two-state bells do not test CDC, sensor timing, or actual reset.

Two-state sampling excludes propagation, CDC, analog sensor latency, alert-link faults and reset/wipe details.
Transfer exercise: Add a staging cabinet between request and final collection. These are different asset boundaries. Choose the actual release event before moving the monitor; the original model observes one specified acceptance edge.

Put a buffer after grant. Define whether acceptance or later data delivery is the asset boundary, then move the monitor accordingly.