WEBVTT

1
00:00:00.000 --> 00:00:03.441
Software writes the same configuration twice.

2
00:00:03.441 --> 00:00:06.843
The shadow comparator sees a match and commits
it.

3
00:00:06.843 --> 00:00:11.704
If both writes carry the same wrong value, the
protocol still succeeds.

4
00:00:11.704 --> 00:00:17.077
We distinguish update consistency from permission
to choose that value.

5
00:00:17.333 --> 00:00:22.180
A control/status register, CSR, exposes
configuration or status to software.

6
00:00:22.180 --> 00:00:27.521
A shadow update first stages a value without
changing the committed value used by hardware.

7
00:00:27.521 --> 00:00:30.226
A second matching write completes the update.

8
00:00:30.226 --> 00:00:35.795
Our four-bit RW example starts at restrictive
FAIL=9.

9
00:00:36.083 --> 00:00:42.243
At edge 1, write 6 enters staged storage and
pending becomes true after the edge.

10
00:00:42.243 --> 00:00:44.111
The active CSR is still 9.

11
00:00:44.111 --> 00:00:47.403
At edge 2, another 6 compares with staged=6.

12
00:00:47.403 --> 00:00:52.918
The update commit occurs on that edge; active
storage changes afterward.

13
00:00:52.918 --> 00:00:59.095
This CSR commit means accepted configuration
update, not instruction retirement.

14
00:00:59.375 --> 00:01:02.783
If the second value is 7, the pair fails.

15
00:01:02.783 --> 00:01:07.838
The committed value remains 9 and an update error
is recorded.

16
00:01:07.838 --> 00:01:12.408
That is a detected inconsistency in the write
protocol.

17
00:01:12.408 --> 00:01:19.668
It says nothing about a persistent storage error
after a successful update; that target needs a

18
00:01:19.668 --> 00:01:21.990
separate checker and test.

19
00:01:22.250 --> 00:01:27.016
OpenTitan documents paired shadow writes,
update/storage error distinctions and reset

20
00:01:27.016 --> 00:01:27.557
concerns.

21
00:01:27.557 --> 00:01:32.123
Our compact protocol omits its complemented
storage, read-to-reset-phase behavior and

22
00:01:32.123 --> 00:01:33.385
specific bus semantics.

23
00:01:33.385 --> 00:01:37.883
It must not be presented as a replica of
prim_subreg_shadow.

24
00:01:38.167 --> 00:01:41.724
The expected configuration in this scenario is 9.

25
00:01:41.724 --> 00:01:46.680
Two writes of 6 match each other but not the
independent policy reference.

26
00:01:46.680 --> 00:01:48.998
Pair-only hardware accepts them.

27
00:01:48.998 --> 00:01:54.273
The monitor records an unauthorized update even
though no mismatch occurred.

28
00:01:54.273 --> 00:01:58.474
Repeating data is not a second policy decision.

29
00:01:58.750 --> 00:02:05.069
A policy-bound variant requires each accepted
write to equal an independently justified

30
00:02:05.069 --> 00:02:06.196
expected value.

31
00:02:06.196 --> 00:02:09.337
The lab gets that value from a trusted harness.

32
00:02:09.337 --> 00:02:14.812
A product may instead enforce privilege,
lifecycle and permitted field values.

33
00:02:14.812 --> 00:02:20.442
Whatever policy is used must protect its source
and the final write enable.

34
00:02:20.708 --> 00:02:27.007
Lock has a different job: after configuration is
frozen, no writes may enter either phase.

35
00:02:27.007 --> 00:02:29.656
Our locked control refuses both beats.

36
00:02:29.656 --> 00:02:35.755
For the separate lock fault, one transient force
clears lockSeen for the two-beat window.

37
00:02:35.755 --> 00:02:41.016
Correct matching data can then change a locked
register.

38
00:02:41.292 --> 00:02:47.501
A split reset can reset the active CSR while
preserving staged data and pending.

39
00:02:47.501 --> 00:02:53.151
After edge 1, our deliberately broken reset
target restores only value=9.

40
00:02:53.151 --> 00:02:59.071
At edge 2, the preserved pending phase treats the
next write as the second beat.

41
00:02:59.071 --> 00:03:05.231
With first=second=expected=9, it commits even
though reset canceled the first beat in the

42
00:03:05.231 --> 00:03:06.802
independent reference.

43
00:03:06.802 --> 00:03:10.369
This is a reset-epoch violation with correct
data.

44
00:03:10.625 --> 00:03:15.335
This scenario declares the reset target and
retained fields explicitly.

45
00:03:15.335 --> 00:03:19.356
It is not a single-bit flip or an OpenTitan
behavior claim.

46
00:03:19.356 --> 00:03:22.831
Reset clears the independent referencePending.

47
00:03:22.831 --> 00:03:29.166
Coherent reset also clears DUT pending: edge 2
has pending=false and no commit; afterward that

48
00:03:29.166 --> 00:03:31.021
write stages a new first beat.

49
00:03:31.021 --> 00:03:38.118
Edge 3 has pending=true and value=9, still the
reset value, not a completed update.

50
00:03:38.118 --> 00:03:43.856
A product must specify value, phase, lock and
error-history reset together.

51
00:03:44.125 --> 00:03:47.685
Interleaved writers create another protocol
concern.

52
00:03:47.685 --> 00:03:52.831
If interrupt code writes between the pair, the
second beat might belong to a different

53
00:03:52.831 --> 00:03:53.546
operation.

54
00:03:53.546 --> 00:04:00.331
Atomic software access or an explicit transaction
protocol can prevent accidental mixing; neither

55
00:04:00.331 --> 00:04:04.362
automatically blocks a faulted lock or common
wrong data.

56
00:04:04.625 --> 00:04:09.231
Choose first=6, second=7, expected=9 and pair
policy.

57
00:04:09.231 --> 00:04:12.887
Inspect edge 3: value remains 9 and bad is true.

58
00:04:12.887 --> 00:04:14.762
Change only second to 6.

59
00:04:14.762 --> 00:04:20.199
There is one commit at edge 2, bad stays false,
and reference is false.

60
00:04:20.199 --> 00:04:24.471
Export this equal-wrong pair before trying
policy-bound.

61
00:04:24.750 --> 00:04:28.575
The Node campaign enumerated all 256 four-bit
write pairs.

62
00:04:28.575 --> 00:04:29.663
Sixteen matched.

63
00:04:29.663 --> 00:04:35.680
Fifteen matching values differed from expected=9
and were unauthorized under pair-only policy.

64
00:04:35.680 --> 00:04:37.928
Policy-bound rejected those cases.

65
00:04:37.928 --> 00:04:43.364
A matching authorized pair committed once;
mismatches never changed the active value.

66
00:04:43.625 --> 00:04:48.177
Set both writes and expected to 9 before the lock
experiment.

67
00:04:48.177 --> 00:04:51.250
Set locked true and target none: no commit.

68
00:04:51.250 --> 00:04:57.053
Change only target to lock: correct data now
bypasses the trusted locked policy.

69
00:04:57.053 --> 00:05:03.783
Then clear locked and compare none, partial-reset
and coherent-reset: they commit once, commit

70
00:05:03.783 --> 00:05:09.418
outside the reset epoch, and stage a new first
beat without committing, respectively.

71
00:05:09.418 --> 00:05:12.702
Policy-bound cannot repair retained phase.

72
00:05:12.958 --> 00:05:14.952
The fragment is uncompiled.

73
00:05:14.952 --> 00:05:19.737
It lacks complete reset, bus response,
byte-enable and access-type logic.

74
00:05:19.737 --> 00:05:25.643
A product must test lock polarity, readback
behavior, storage checking, phase integrity and

75
00:05:25.643 --> 00:05:26.390
reset skew.

76
00:05:26.390 --> 00:05:32.343
The next lesson measures when an error signal
actually prevents the accepted operation.

77
00:05:32.625 --> 00:05:38.077
Four-bit RW CSR, two writes at edges 1/2, one
update acceptance at edge 2.

78
00:05:38.077 --> 00:05:44.625
Common wrong pair, lock force and committed-only
reset are separate protocol cases.

79
00:05:44.875 --> 00:05:51.668
Node ran all 256 write pairs, lock/reset
witnesses and an exactly-once authorized pair.

80
00:05:51.668 --> 00:05:54.567
No complete CSR RTL or bus test ran.

81
00:05:54.833 --> 00:06:00.440
This simplified protocol excludes complemented
storage, byte masks, read semantics, concurrent

82
00:06:00.440 --> 00:06:02.850
writers and physical reset behavior.