WEBVTT

1
00:00:00.000 --> 00:00:02.560
軟體把組態寫兩次。

2
00:00:02.560 --> 00:00:06.420
Shadow 比較器看到相符，便提交更新。

3
00:00:06.420 --> 00:00:10.820
若兩次都是同一錯值，協定仍會成功。

4
00:00:10.820 --> 00:00:15.240
本課分開檢查更新一致性，以及是否有權選這個值。

5
00:00:15.640 --> 00:00:20.340
控制／狀態暫存器稱為 CSR，供軟體讀寫組態或狀態。

6
00:00:20.340 --> 00:00:23.940
Shadow 更新先暫存值，不改硬體正在使用的 committed value。

7
00:00:23.940 --> 00:00:25.720
第二次相符才完成。

8
00:00:25.720 --> 00:00:29.880
本課四位元 RW 範例從限制值 FAIL＝9 開始。

9
00:00:30.320 --> 00:00:34.220
Edge 1 寫 6，該緣後 staged 保存 6，pending 變 true，使

10
00:00:34.220 --> 00:00:35.820
用中的 CSR 仍為 9。

11
00:00:35.820 --> 00:00:38.280
Edge 2 再寫 6，與 staged 相符。

12
00:00:38.280 --> 00:00:42.360
更新 commit 在該緣發生，使用值之後才改。

13
00:00:42.360 --> 00:00:45.760
CSR commit 指組態更新被接受，不是指令退休。

14
00:00:46.220 --> 00:00:50.600
第二次若寫 7，配對失敗，使用值維持 9，並記錄更新錯誤。

15
00:00:50.600 --> 00:00:53.060
這只辨認寫入協定不一致。

16
00:00:53.060 --> 00:00:57.160
成功更新後若保存值出錯，仍需要另外的檢查與測試。

17
00:00:57.580 --> 00:01:03.120
OpenTitan 文件說明成對 shadow 寫入、更新與保存錯誤，以及 reset 問題。

18
00:01:03.120 --> 00:01:08.420
本課簡化協定省略反相保存、讀取重置 phase 與特定 bus 語意，不能說成

19
00:01:08.420 --> 00:01:09.800
prim_subreg_shadow 複刻。

20
00:01:10.280 --> 00:01:12.780
本情境預期組態是 9。

21
00:01:12.780 --> 00:01:17.360
兩次寫 6 彼此相符，卻不符合獨立政策 reference。

22
00:01:17.360 --> 00:01:21.240
只查配對的硬體會接受，monitor 因而記越權。

23
00:01:21.240 --> 00:01:23.620
重複資料沒有提供第二次政策判斷。

24
00:01:24.260 --> 00:01:29.140
Policy-bound 要求每次接受寫入，符合另有可信依據的預期值。

25
00:01:29.140 --> 00:01:31.460
實驗從可信 harness 取得它。

26
00:01:31.460 --> 00:01:35.320
產品可以改查權限、生命週期與欄位允許值。

27
00:01:35.320 --> 00:01:38.340
政策來源與最終 write enable 都須保護。

28
00:01:38.340 --> 00:01:43.620
Lock 另有工作：組態凍結後，兩個 phase 都不得再接受寫入。

29
00:01:43.620 --> 00:01:46.000
Locked 控制會拒絕兩筆。

30
00:01:46.000 --> 00:01:51.220
另一組 lock 故障，以一次暫時強制，讓 lockSeen 在兩筆窗口都清零。

31
00:01:51.220 --> 00:01:53.680
資料配對正確，仍能改到鎖定暫存器。

32
00:01:54.000 --> 00:01:59.020
分離 reset 可能只重置使用中的 CSR，卻保留 staged 與 pending。

33
00:01:59.020 --> 00:02:03.680
本課刻意錯誤的 reset 目標在 edge 1 後，只恢復 value＝9。

34
00:02:03.680 --> 00:02:06.320
Edge 2 仍保留第二筆 phase。

35
00:02:06.320 --> 00:02:11.380
設 first＝second＝expected＝9，資料正確，DUT 卻把 reset

36
00:02:11.380 --> 00:02:13.640
前的第一筆接上 reset 後的第二筆。

37
00:02:13.640 --> 00:02:17.580
獨立判準已取消舊階段，因此這次提交越權。

38
00:02:17.940 --> 00:02:24.400
本情境明列 reset 目標及保留欄位，不是單位元翻轉，也沒有宣稱 OpenTitan 有此行為。

39
00:02:24.400 --> 00:02:26.800
Reset 清除獨立 referencePending。

40
00:02:26.800 --> 00:02:30.240
一致 reset 也清除 DUT pending：edge 2 的 pending＝

41
00:02:30.240 --> 00:02:33.960
false，不提交；該筆之後暫存為新的第一筆。

42
00:02:33.960 --> 00:02:40.140
Edge 3 的 pending＝true、value＝9；9 仍是重置值，不是完成更新的結果。

43
00:02:40.140 --> 00:02:43.900
產品須一起定義 value、phase、lock 與錯誤歷史的 reset。

44
00:02:44.600 --> 00:02:46.860
交錯寫入是另一個協定問題。

45
00:02:46.860 --> 00:02:50.560
若中斷程式插入一筆，第二筆可能屬於別的操作。

46
00:02:50.560 --> 00:02:56.540
軟體原子存取或明確交易協定能避免混用，但它們不會自動擋住受擾 lock 或共同錯值。

47
00:02:57.250 --> 00:03:01.910
選 first＝6、second＝7、expected＝9 與 pair。

48
00:03:01.910 --> 00:03:05.530
看 edge 3：value 仍為 9，bad 為 true。

49
00:03:05.530 --> 00:03:09.290
只改 second＝6，edge 2 會有一次 commit，bad 為 false，

50
00:03:09.290 --> 00:03:11.110
reference 卻為 false。

51
00:03:11.110 --> 00:03:13.610
先匯出相符錯值，再試 policy-bound。

52
00:03:14.410 --> 00:03:19.290
已執行枚舉遍歷 256 組四位元寫入配對，十六組相符。

53
00:03:19.290 --> 00:03:24.290
其中十五種相符值不等於 expected＝9，pair 政策因此越權。

54
00:03:24.290 --> 00:03:26.410
Policy-bound 拒絕這些組合。

55
00:03:26.410 --> 00:03:29.870
合法相符配對只提交一次；不一致不改使用值。

56
00:03:30.550 --> 00:03:34.490
先把兩筆與 expected 都設為 9，再做 lock 實驗。

57
00:03:34.490 --> 00:03:37.890
設 locked＝true、target＝none：不提交。

58
00:03:37.890 --> 00:03:42.070
只改 target＝lock：正確資料仍繞過可信鎖定政策。

59
00:03:42.070 --> 00:03:44.690
接著清除 locked，比較 none、partial-reset 與

60
00:03:44.690 --> 00:03:51.830
coherent-reset：分別正常提交一次、跨 reset 越權提交，以及只暫存新第一筆而不提交。

61
00:03:51.830 --> 00:03:53.770
Policy-bound 無法修復保留的 phase。

62
00:03:54.210 --> 00:04:00.390
片段尚未編譯，沒有完整 reset、bus 回應、byte enable 與存取型態。

63
00:04:00.390 --> 00:04:07.010
產品須測 lock 極性、讀回、保存檢查、phase 完整性與 reset skew。

64
00:04:07.010 --> 00:04:10.410
下一課會量出錯誤訊號何時真正阻止接受。

65
00:04:11.190 --> 00:04:17.170
四位元 RW CSR，edge 1／2 寫兩筆，edge 2 接受更新。

66
00:04:17.170 --> 00:04:20.970
共同錯值、lock 強制與只重置 committed 的案例分開。

67
00:04:21.590 --> 00:04:27.450
Node 已跑 256 組配對、lock／reset 反例與合法配對一次提交。

68
00:04:27.450 --> 00:04:30.630
尚未跑完整 CSR RTL 或 bus 測試。

69
00:04:31.250 --> 00:04:37.210
簡化協定排除反相保存、byte mask、讀取語意、並行寫入與實體 reset 行為。

