WEBVTT

1
00:00:00.000 --> 00:00:02.760
接收端在 edge 2 接受錯誤請求。

2
00:00:02.760 --> 00:00:06.060
Sticky 之後記下異常，系統更晚才 reset。

3
00:00:06.060 --> 00:00:10.120
Alert 確實工作，卻無法撤回已接受的請求。

4
00:00:10.120 --> 00:00:13.460
本課把偵測與回應放到接受緣旁邊。

5
00:00:14.160 --> 00:00:16.240
偵測器辨認異常。

6
00:00:16.240 --> 00:00:20.020
局部阻擋防止這個區塊交出操作。

7
00:00:20.020 --> 00:00:25.680
Alert 把報告送到系統政策，後者可能中斷、清除或重置。

8
00:00:25.680 --> 00:00:28.200
這些是不同事件，延遲也可能不同。

9
00:00:29.560 --> 00:00:32.520
儲存 upset 在 edge f 後作用。

10
00:00:32.520 --> 00:00:35.700
錯誤許可最早在 f＋1 出現。

11
00:00:35.700 --> 00:00:40.700
偵測在 f＋1＋D 出現，D 為零到四的整數延遲。

12
00:00:40.700 --> 00:00:43.220
系統阻擋再晚 R 個緣。

13
00:00:43.220 --> 00:00:44.980
請求只在指定緣接受。

14
00:00:46.200 --> 00:00:49.780
這些是教學緣數，沒有量測 OpenTitan。

15
00:00:49.780 --> 00:00:53.700
它的 alert handler 文件描述系統升級機制。

16
00:00:53.700 --> 00:01:00.060
產品須從實作與時序證據導出延遲上限，也要包含來源到接收端路徑。

17
00:01:00.480 --> 00:01:07.020
F＝1、D＝0 時，edge 2 的目前 bad 為 true，舊 sticky 卻為 false。

18
00:01:07.020 --> 00:01:10.700
Local 政策要求兩者皆清零，因此會擋。

19
00:01:10.700 --> 00:01:12.700
只看 sticky 則接受。

20
00:01:12.700 --> 00:01:15.780
Sticky 之後才更新，無法改掉已記錄的接受。

21
00:01:16.820 --> 00:01:20.740
D＝1 時，local 在 edge 2 也還沒偵測。

22
00:01:20.740 --> 00:01:25.720
錯誤 grant 已可見，因此請求先 commit，edge 3 才報錯。

23
00:01:25.720 --> 00:01:29.060
當拍錯誤閘要有用，該錯誤本身就必須先到。

24
00:01:29.780 --> 00:01:33.520
System 政策等到 f＋1＋D＋R 才阻擋。

25
00:01:33.520 --> 00:01:39.680
較晚 reset 能停止後續工作並協助復原，但無法撤銷不可逆交付。

26
00:01:39.680 --> 00:01:43.180
第一次越權接受與後續成功通報，必須分開報告。

27
00:01:43.440 --> 00:01:47.800
儲存主表只注入一次持續 upset，f 為 0～5。

28
00:01:47.800 --> 00:01:53.640
D 為 0～4，請求緣為 0～8，完整表固定 R＝2。

29
00:01:53.640 --> 00:01:57.180
觀察到 edge 8，sticky 初始 false。

30
00:01:57.180 --> 00:02:00.380
映像 reference 與非目標偵測／回應電路保持可信。

31
00:02:00.380 --> 00:02:05.420
最終 grant 另測：儲存維持正確，只在接受緣反相 grant。

32
00:02:05.420 --> 00:02:09.020
前面的局部阻擋無法控制這個下游強制。

33
00:02:09.020 --> 00:02:12.160
這沒有測請求 buffer 或接受機制內部故障。

34
00:02:12.600 --> 00:02:17.580
時脈與 reset 故障、alert 連線失效、clear／wipe 順序、拍內

35
00:02:17.580 --> 00:02:21.360
pulse 及類比感測器，都不在兩態緣模型內。

36
00:02:21.360 --> 00:02:25.340
可信偵測器是假設，沒有證明實體偵測來得及。

37
00:02:25.340 --> 00:02:27.560
真正訊號必須在接受緣前穩定。

38
00:02:27.898 --> 00:02:33.558
從 f＝1、D＝0、request edge＝2、local 開始。

39
00:02:33.558 --> 00:02:38.198
看到 edge 2：bad 為 true、sticky 為 false、commit 為 false。

40
00:02:38.198 --> 00:02:41.498
改 sticky，匯出越權軌跡。

41
00:02:41.498 --> 00:02:44.778
再回 local，把 D 改為一。

42
00:02:44.778 --> 00:02:46.638
第一筆此時也能繞過局部阻擋。

43
00:02:47.758 --> 00:02:56.798
已執行 810 條儲存時序流跡：六個故障緣、五種偵測延遲、九個請求緣與三政策，R＝2。

44
00:02:56.798 --> 00:03:04.658
另一組系統政策枚舉涵蓋 R＝0～4，共 1,350 條；local 與 sticky 不使用 R。

45
00:03:04.658 --> 00:03:10.218
獨立區間斷言核對越權窗口，並以直接邊緣反例檢查公式。

46
00:03:10.218 --> 00:03:14.458
Corrupt 是另一個時序模型，沒有接上第四到九課的偵測器。

47
00:03:15.098 --> 00:03:20.418
三政策的無故障授權控制都接受，無故障未授權都拒絕。

48
00:03:20.418 --> 00:03:27.898
故障生效前沒有越權，是錯誤許可還未可見；阻擋後拒絕，則是處置生效。

49
00:03:27.898 --> 00:03:30.638
兩種沒有 commit 的原因，應分開解釋。

50
00:03:31.065 --> 00:03:36.425
RTL／SVA 尚未編譯，需要明確的組合時序路徑與可信接受端。

51
00:03:36.425 --> 00:03:42.185
系統回應要分別限制偵測到 alert、alert 到動作，也要驗證持續阻擋。

52
00:03:42.185 --> 00:03:47.605
第十一課會加入 reset、clock、CDC 與生命週期，這些目前仍為規劃。

53
00:03:47.905 --> 00:03:56.445
Edge f 後一次儲存 upset；f＋1＋D 偵測，請求緣為 0～8，系統回應晚 R 緣。

54
00:03:56.445 --> 00:03:58.445
最終 grant 強制另測。

55
00:03:58.965 --> 00:04:05.985
Node 已跑 R＝2 的 810 條三政策時序流跡，以及 R＝0～4 的 1,350

56
00:04:05.985 --> 00:04:09.705
條系統流跡、區間檢查、grant 反例與授權控制。

57
00:04:09.705 --> 00:04:12.285
RTL 與 timing closure 尚未驗證。

58
00:04:12.845 --> 00:04:19.265
兩態取樣排除傳播、CDC、類比偵測延遲、alert 連線故障及 reset／wipe 細節。