WEBVTT

1
00:00:00.000 --> 00:00:04.178
Reset release is not one simultaneous
instant across the chip.

2
00:00:04.178 --> 00:00:09.132
If permission crosses a clock domain or
precedes startup checks, it may be used

3
00:00:09.132 --> 00:00:11.609
while the system appears to be booting.

4
00:00:11.609 --> 00:00:17.584
A hospital backup-power transfer makes the
point: lights can be on before every ward

5
00:00:17.584 --> 00:00:22.923
has passed its checks. A controller waits
for stable power, self-tests, and then

6
00:00:22.923 --> 00:00:24.729
enables selected outlets.

7
00:00:24.729 --> 00:00:31.593
A chip must likewise distinguish stable
power, reset release, valid OTP/lifecycle

8
00:00:31.593 --> 00:00:36.692
data, ROM checks, and CPU fetch enable.
These are separate events.

9
00:00:36.692 --> 00:00:40.069
The analogy only conveys staged readiness;

10
00:00:40.069 --> 00:00:44.415
it does not model asynchronous reset
networks, metastability,

11
00:00:44.415 --> 00:00:46.615
or fused lifecycle states.

12
00:00:46.875 --> 00:00:50.268
List reset assertion and deassertion in each
domain.

13
00:00:50.268 --> 00:00:53.318
Asynchronous assertion can clear state
promptly;

14
00:00:53.318 --> 00:00:57.220
deassertion is commonly synchronized to each
destination clock

15
00:00:57.220 --> 00:00:59.633
to avoid recovery/removal violations.

16
00:00:59.633 --> 00:01:05.245
OpenTitan’s public lifecycle-controller
theory describes waiting for OTP sensing,

17
00:01:05.245 --> 00:01:10.529
decoding and broadcasting lifecycle, then
checking straps/ROM after stabilization.

18
00:01:10.529 --> 00:01:15.241
That is a design-specific document, not a
timing guarantee for every product.

19
00:01:15.241 --> 00:01:19.653
A one-bit ready pulse sampled directly
across domains may be missed.

20
00:01:19.653 --> 00:01:24.287
Synchronizing each bit of a multi-bit
lifecycle bus independently can instead

21
00:01:24.287 --> 00:01:29.128
produce a combination that never existed
because bits arrive on different cycles.

22
00:01:29.128 --> 00:01:34.659
Transfer data with a handshake or stable
encoding, and authorize using reset state

23
00:01:34.659 --> 00:01:39.497
synchronized locally. For split reset
groups, examine transactions and FIFO

24
00:01:39.497 --> 00:01:43.235
clearing while the producer is awake but the
consumer is not.

25
00:01:43.235 --> 00:01:46.443
A CDC report is structural evidence;

26
00:01:46.443 --> 00:01:49.509
it does not prove lifecycle policy.

27
00:01:49.792 --> 00:01:55.106
Counterexample: ROM check completes in
clk_sys, but debug permission reaches

28
00:01:55.106 --> 00:01:59.228
clk_dbg first. If clk_dbg runs faster, it
can accept halt before

29
00:01:59.228 --> 00:02:02.128
clk_dbg observes synchronized check_done.

30
00:02:02.128 --> 00:02:07.840
Assert at the actual debug-accept boundary,
not only on the reset controller’s eventual

31
00:02:07.840 --> 00:02:11.239
state. The SVA below is a harness proposal,
not compiled;

32
00:02:11.239 --> 00:02:15.418
every debug_accept requires stable lifecycle
and a completed check.

33
00:02:15.418 --> 00:02:20.860
Test reset release order, pause or speed
each domain, inject one-cycle cross-domain

34
00:02:20.860 --> 00:02:24.222
requests, repeat reset, and cover each
lifecycle value.

35
00:02:24.222 --> 00:02:28.542
Positive controls must show that an
authorized startup eventually becomes

36
00:02:28.542 --> 00:02:32.401
usable; safety checks must show no
acceptance before prerequisites hold.

37
00:02:32.401 --> 00:02:38.198
An edge model cannot replace CDC/RDC
analysis, reset-tree timing, power-ramp

38
00:02:38.198 --> 00:02:41.367
testing, or analog brownout validation.

39
00:02:41.625 --> 00:02:46.969
These are property sketches: define the
harness transaction, reset and oracle, then

40
00:02:46.969 --> 00:02:50.541
confirm sampling boundaries before binding
to the design.

41
00:02:50.541 --> 00:02:52.827
They have not been compiled or proven.

42
00:02:52.827 --> 00:02:58.658
This snippet does not prove CDC, timing,
side-channel, or physical injection

43
00:02:58.658 --> 00:03:03.019
behavior; each requires its own tool
evidence or measurement.

44
00:03:03.019 --> 00:03:05.899
Walk the same startup across two domains.

45
00:03:05.899 --> 00:03:11.627
The system clock may finish the ROM check
while the debug domain has already released

46
00:03:11.627 --> 00:03:16.729
its local reset. If permission arrives
first, debug_accept can occur before the

47
00:03:16.729 --> 00:03:19.881
destination observes synchronized
check_done.

48
00:03:19.881 --> 00:03:25.117
Sweep clock phase, pause or speed either
domain, and repeat reset.

49
00:03:25.117 --> 00:03:28.658
Record the values visible at the accepting
edge.

50
00:03:28.658 --> 00:03:33.408
This can expose an ordering counterexample
in the digital model.

51
00:03:33.408 --> 00:03:39.317
It cannot estimate metastability probability
or represent the analog power ramp.

52
00:03:39.583 --> 00:03:43.721
During startup, debug permission and ROM
check_done belong to different clock

53
00:03:43.721 --> 00:03:48.247
domains. After destination reset releases,
permission may arrive before the destination

54
00:03:48.247 --> 00:03:50.069
observes synchronized check_done.

55
00:03:50.069 --> 00:03:55.677
Accepting then allows reset-release order
and clock phase to expose a path whose check

56
00:03:55.677 --> 00:04:00.814
is incomplete. Synchronize reset release in
each domain and handshake lifecycle and

57
00:04:00.814 --> 00:04:04.595
check status. Check stable conditions
locally at acceptance.

58
00:04:04.595 --> 00:04:11.422
Enumerate phase and state combinations,
retain positive startup controls, and obtain

59
00:04:11.422 --> 00:04:15.157
separate CDC/RDC structural and timing
evidence.

60
00:04:15.157 --> 00:04:19.326
This lesson has not run RTL, formal
verification, or STA.

61
00:04:19.326 --> 00:04:25.412
The teaching event-order model excludes
metastability probability, analog power, the

62
00:04:25.412 --> 00:04:28.596
actual reset tree, and physical lifecycle
fuses.

63
00:04:28.596 --> 00:04:31.932
Change the destination frequency and add a
CDC FIFO.

64
00:04:31.932 --> 00:04:36.772
Which reset groups may restart
independently, and what minimum evidence

65
00:04:36.772 --> 00:04:38.848
must the accepting endpoint have?

66
00:04:38.848 --> 00:04:43.789
At permission arrival, inspect the check
state actually observed in that domain.

67
00:04:43.789 --> 00:04:48.646
If it is uncertain, vary clock phase,
pauses, and reset conditions.

68
00:04:48.646 --> 00:04:52.905
The evidence must match the moment
permission is accepted.