重置解除不是一個全晶片同時發生的瞬間。安全許可若跨時鐘域或早於啟動檢查，就可能在系統「看起來已經開機」時先被使用。
學習目標與課堂安排
完成本課後，你應能：
- 算出短脈衝在理想相位模型的漏取條件及兩級同步延遲。
- 逐事件追蹤握手，說明資料保持、停鐘與獨立 reset 的處理。
- 在 debug 接受邊界區分 DUT 旗標與獨立授權證據。
建議 50 分鐘的教師安排：先備概念 10 分鐘、時序手算 15 分鐘、握手與互動 15 分鐘、reset 反例討論 10 分鐘。時間含學生手算、互動與討論；這是教學規劃，尚未做學生課堂時間量測。
啟動是一段有條件的序列
想像醫院備援發電切換：燈亮不代表每個病房都已完成自我檢查。管理員必須等電源穩定、設備自測通過，再開放特定插座。晶片也要分辨電源穩定、reset 解除、OTP/生命週期資料有效、ROM 檢查完成與 CPU 可取指；這些事件不是同義詞。生活類比只能提示「逐項就緒」，醫院沒有對應的非同步 reset 網路、亞穩態或多個安全熔絲狀態。
先把每個時域的 reset assertion 與 deassertion 列成事件。非同步 assert 可快速拉低狀態；deassert 通常要在各目的時鐘域同步，避免 recovery/removal 違例。OpenTitan lifecycle controller 的公開理論描述先等待 OTP sensing，再解碼並廣播 lifecycle，待穩定後才檢查 strap/ROM；這是特定設計文件，不可直接當成所有產品的時序保證。Lifecycle controller。
單一 ready bit 跨域若直接取樣，短脈衝可能漏掉；多位元 lifecycle bus 即使每一位都有雙觸發器，也可能在不同週期到達而組成從未存在的值。用握手/穩定編碼傳輸資料，並讓目的域以本地同步 reset 狀態授權。不同 reset 分組還要檢查 producer 已醒、consumer 尚未醒時的交易與 FIFO 清空。CDC 工具報告是結構證據，不會證明生命週期政策正確。
失敗反例：ROM check 已在 clk_sys 完成，但 clk_dbg 尚未同步看到 check_done。若 permission 先到，目的域便提前接受 debug。安全性質要寫在真正接受 debug 的邊界，而非只查 reset controller 最終狀態。文末的片段是待接入 harness 的 SVA 草案，尚未編譯；debug_accept 每次成立都必須有已穩定的 lifecycle 與完成檢查。
驗收邊界
測試 reset 解除順序、任一域暫停/加速、跨域單拍請求、重複 reset，以及各 lifecycle 值。正向控制要證明合法啟動最終可用；安全性則要求條件未滿足時沒有接受。這種以時脈邊緣為單位的模型，不能代替 RDC/CDC 分析、reset-tree STA、電源斜率測試或類比 brownout 驗證。
實作案例：檢查完成，為什麼 debug 還不能用？
沿用一顆有 ROM 啟動檢查與 debug 介面的教學晶片。ROM 在 clk_sys 運作，debug 接受端在 clk_dbg 運作。管理軟體看見來源端的檢查完成，便送出 debug 請求；但目的域尚未觀察到這次完成事件。請先預測：如果 debug 只看 permission，哪一個瞬間會出錯？
這裡要區分三件事：來源完成了工作、目的域收到完成證據、目的域接受請求。第一件事成立，不會使第二件事自動成立。若 permission 和 check_done 分別經過不同傳輸路徑，兩者抵達順序可能不同。即使最後都變成 1，提前接受過的交易也不會因此恢復合法。安全性質應檢查每次 debug_accept 發生時的條件，並保留當時的波形。
下面依本課互動模型手算。step 是共用教學事件順序，不是某個域的真實 clock cycle；check 表示本案例在 step 2 產生 check_done 完成事件，sync 表示目前 step 的目的域已觀察到同步後的 check_done。模型定義 checkAvailable = check && step >= 2，接著計算 destObserved = checkAvailable && sync。在已提出且另有合法許可的請求前提下，閘控政策的 accept 等於 destObserved。這些布林值沒有模擬同步器延遲或亞穩態。
| 教學 step | check | sync | checkAvailable | destObserved | permission | weakAccept | weakAcceptEarly | 閘控 accept |
|---|---|---|---|---|---|---|---|---|
| 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 0 |
| 2 | 1 | 0 | 1 | 0 | 1 | 1 | 1 | 0 |
| 2 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 |
| 3 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 0 |
操作對照：permission 的 step 滑桿依序設為 1、2、2、3；check 方塊依序為勾選、勾選、勾選、取消；sync 方塊依序為取消、取消、勾選、勾選。permission = 1 與 weakAccept = permission 是本文補上的比較假設，介面沒有這兩個新增控制項。介面「弱政策提前接受」對應 weakAcceptEarly = weakAccept && !destObserved，與所有接受次數不同；第三列弱政策會接受，但沒有提前接受。
第二列最容易被誤判。來源完成事件已成立，但目的域觀察仍為 0；弱政策此時若只憑 permission 接受，就得到「先使用、後取得證據」的反例。第三列才是此 check_done 閘控子模型的正向列：檢查與目的域觀察皆成立，合法請求可以接受。第四列則提醒我們，將目的域觀察輸入設為 1，不會憑空產生來源完成事件；模型仍令觀察結果為 0。真實設計也不能把「接了 synchronizer」當成授權。
把結果帶回真實時鐘域
真實設計至少需要兩張事件表。一張記錄來源檢查何時完成、資料何時穩定；另一張記錄目的域何時收到並接受。跨域時間不能直接用來源的第幾拍代替目的的第幾拍。若 clk_dbg 暫停，來源可以完成檢查，但目的端仍未得到新的觀察；目的端必須維持拒絕，或依明確定義的逾時政策處理。
一個單拍脈衝在來源域可能清楚可見，到了較慢或暫停的目的域卻完全沒有被取樣。若該事件不能遺失，可採保持請求直到確認的握手，或使用適合事件傳送的編碼；具體電路仍需依 clock/reset 條件驗證。讀者不應從上表的 sync = 1 推出「用了兩級觸發器，所以脈衝一定送達」。上表只展示接受政策，沒有建模脈衝寬度。
多位元 lifecycle 值還有另一種失敗。假設來源由二位元值 01 轉成 10，目的端若把兩個 bit 分開同步，可能短暫看到 00 或 11。這是說明位元一致性問題的假設例子，不是指定晶片的合法狀態編碼。即使每一位都通過 CDC 結構檢查，組合值是否屬於同一次更新仍須由協定保證；授權解碼器也要明確處理保留或非法值。
最後再加入獨立 reset：producer 重啟、consumer 保持運作，FIFO 中卻留著前次啟動的完成訊息。訊息內容可以是正確的，所屬的啟動卻已過期。設計必須決定清空、排空或用新的 boot epoch 識別訊息；epoch 在此是建議的交易世代概念，互動模型並未實作它。Reset 處理還需決定哪些在途證據仍有資格被使用。
延伸練習：從布林表走到驗證計畫
練習 A：定位第一個反例。 固定 check 為 1，先在 step 2 關閉 sync，再開啟 sync。各記錄一次弱政策與閘控政策的接受結果。若弱政策在目的域觀察前已接受，後來把 sync 打開，能否撤銷反例？
解答與推導： 不能。安全事件已在早先的接受邊界發生。報告應保留當次請求、接受時間與當時的目的域觀察，不用最終 ready 狀態覆蓋它。閘控政策則在觀察尚未成立時拒絕，觀察成立後才允許；合法接受那一列也要保留，避免用「永遠不接受」取得表面安全。
練習 B：設計一個模型外測試。 目的時鐘停住時，來源送出一拍 check_done，之後來源清除該脈衝。列出需要觀察的訊號，以及現有互動模型缺少的資訊。
解答與推導： 需要來源脈衝寬度、目的時鐘邊緣、握手請求與確認、資料保持期間，以及目的端接受事件。現有模型沒有這些連續或逐域時間，因此只能提出測試計畫，不能宣稱已測得漏拍。若採用握手，還要檢查 reset 發生在請求與確認之間時如何恢復，避免補救措施造成永久等待。
練習 C：審查 reset 排除條件。 下方 SVA 草案以目的域 reset 排除檢查。若 debug 接受端在 reset 期間仍能對外產生副作用，assertion 通過是否足夠？
解答與推導： 不足。disable iff 讓性質在該期間不檢查，不會自動阻止硬體接受。要另定義 reset 期間的介面契約並取得證據：例如接受端是否確實被隔離、外部請求是否保留、解除後如何重新授權。此練習要求指出證據缺口，沒有聲稱這份 SVA 已編譯或證明。
課堂推導：從時鐘週期算出漏拍條件
先備知識是邊緣觸發的 D flip-flop。Setup/hold 要求資料在取樣邊緣前後保持穩定；非同步 reset 的解除則受 recovery/removal 時間限制。兩級同步器讓第一級可能的亞穩態多一段恢復時間，第二級在下一個目的時鐘邊緣讀取第一級的舊值。這種結構降低亞穩態傳播風險；短脈衝能否被第一級取樣，仍是另一個問題。
設來源時鐘為 200 MHz，週期 5 ns；目的時鐘為 25 MHz，週期 40 ns。新增手算模型令來源脈衝只在 [0, 5) ns 為高，目的端取樣相位為 φ，0 ≤ φ < 40 ns。只有 φ 落在 [0, 5) 才有取樣邊緣碰到高電位。因此相位範圍的占比是 5/40 = 12.5%。這是均勻相位、理想瞬間取樣、忽略 setup/hold 與亞穩態時的幾何占比，不能當成真實電路的可靠度。
| φ | 目的端取樣邊緣（ns） | 是否取到 [0, 5) 的脈衝 |
|---|---|---|
| 2 ns | 2、42、82 | 是，在 2 ns |
| 10 ns | 10、50、90 | 否 |
| 30 ns | 30、70、110 | 否 |
請對照上方四列表：那張表用共用教學 step 展示政策，這張表才給了兩個時鐘的實際單位。為了讓弱政策的反例看得見，在已有合法請求與其他許可的條件下，定義 permission = 1、weakAccept = permission。上方四列的 weakAccept 都為 1；第二列尤其清楚：weakAccept = 1，閘控 accept = 0。這是本文補上的比較欄位，原互動介面沒有新增 permission 控制項。
保持請求之後，兩級同步仍需要時間
換成持續為高的 req，於 6 ns 上升，目的邊緣在 40、80、120 ns。假設兩級起始皆為 0，理想模型在 40 ns 令 q1 = 1、q2 = 0；80 ns 才令 q2 = 1。相對 req 上升的觀察延遲是 74 ns，約為 1.85 個目的週期。這裡跨了兩個取樣邊緣，卻不是固定等待整整兩個週期；相位與亞穩態都會改變真實延遲。
完整四相握手可按六件事追蹤：來源保持資料並拉高 req；目的同步器觀察 req；目的接收並拉高 ack；來源同步觀察 ack 後拉低 req；目的觀察 req 解除並拉低 ack；來源觀察 ack 解除後結束這輪。資料的保持與釋放時點要由協定定義。若目的時鐘可停住，沒有最大停鐘時間就無法推出有限的完成上界；timeout 的角色是觸發明確的取消或恢復政策，不能假裝傳輸已完成。
將六事件握手接回數值時序
沿用 req 在 6 ns 上升與目的週期 40 ns，再明定來源邊緣為 1、6、11……ns（週期 5 ns），目的邊緣為 0、40、80……ns。兩邊各用兩級同步器，接收端及發送端控制器都是暫存器：同一邊緣讀取更新前的 q2，下一個邊緣才採取動作。所有暫存器初始為 0，忽略亞穩態與 setup/hold。
| 時點 ns | 事件 | 此時資料／協定狀態 |
|---|---|---|
| 6 | 來源拉高 req，資料保持穩定 | 等待 ack |
| 40 | 目的 req 同步第一級取得 1 | 第二級仍為 0 |
| 80 | 目的 req 同步第二級取得 1 | 控制器此拍仍讀到舊 q2=0 |
| 120 | 目的控制器接收資料並拉高 ack | 資料已由接收端保存 |
| 121、126 | 來源 ack 第一級、第二級先後取得 1 | 發送端控制器在 126 ns 仍讀舊值 |
| 131 | 來源控制器觀察 ack，拉低 req | 可依本契約釋放原資料，尚不能開始下一輪 |
| 160、200 | 目的 req 第一級、第二級先後取得 0 | 等待接收端控制器動作 |
| 240 | 目的控制器觀察 req 解除，拉低 ack | 接收端回到等待 |
| 241、246 | 來源 ack 第一級、第二級先後取得 0 | 等待發送端控制器動作 |
| 251 | 來源控制器觀察 ack 解除 | 完成這輪；可開始下一輪 |
q2 的「80 ns 觀察到 req」與控制器「120 ns 接收」是不同事件。兩級同步的 74 ns 延遲仍成立；完整往返還包括控制器取樣及返回同步。在這個明定模型中，資料需保持到 131 ns，下一輪最早 251 ns 開始。更換控制器或時鐘相位就需重算，停鐘與 reset 恢復另依契約驗證。
握手練習： 如果目的時鐘在 80 ns 之後停住，來源最早能在 131 ns 解除 req 嗎？
解答： 不能沿用此表。接收端尚未在 120 ns 保存資料或產生 ack；來源應保持請求及資料，直到重新取得確認，或完成明定的取消／恢復流程。沒有最大停鐘時間，就沒有有限的完成上界。
多位元 01→10 的例子也可以逐位算：bit1 先到，目的端暫見 11；bit0 先到，暫見 00。Gray 相鄰碼只改一位，可減少指定相鄰轉移的位元偏斜歧義，但任意跨碼、跳過多個狀態、故障翻位與授權政策仍需分析。不能把「Gray」直接寫成 lifecycle 安全證明。
計算練習： 保持同樣的 40 ns 目的週期，把理想脈衝寬度改成 10 ns，相位占比是多少？若 req 在 41 ns 上升且持續為高，依上述兩級理想模型，q2 最早在哪個目的邊緣觀察到？
完整解答： 占比為 10/40 = 25%。41 ns 錯過 40 ns 邊緣，80 ns 才由第一級取樣，120 ns 由第二級觀察，延遲 79 ns。這份算例不計亞穩態；真實驗證還要檢查同步器與 reset 的結構、時序約束及握手恢復。SVA 中的 reference_*_sync 應由獨立 harness 依目的域契約決定「應可觀察」時點，不能直接複製 DUT 旗標。
重算與核對
下載程式與結果 JSON 到同一資料夾，以 Python 3.8 以上執行：
python rtl-university-workbook-v1.py --output replay.json比對 replay.json 與提供的結果檔，先核對本課的 lesson11 欄位。sourceSha256 記錄程式檔案的位元組身分，與算例正確性分開檢查；若編輯內容或把 LF 另存成 CRLF，這個值也會改變。保留原下載檔再做練習，並將學生改版另存，才能分辨方法改變與檔案改變。
離線互動實驗
RTL／SVA 審查方向
以下為性質草案：先定義 harness 的 transaction、reset 與 oracle，並確認取樣邊界，再接入設計；尚未編譯或證明。
assert property (@(posedge clk_dbg) disable iff (!rst_dbg_n)
debug_accept |-> reference_lifecycle_stable_sync && reference_rom_check_done_sync);
cover property (@(posedge clk_dbg) disable iff (!rst_dbg_n)
debug_accept && reference_lifecycle_stable_sync && reference_rom_check_done_sync);reference_* 是 harness 中獨立於 DUT 的 oracle。同步旗標只表示目的域已觀察到狀態；它不證明跨域傳輸正確，也不證明來源 lifecycle 合法。
此片段不證明 CDC、timing、side-channel 或實體注入；需由各自工具與測量提供證據。
檢核問題
- 辨認：啟動時哪些事件必須分開處理？ 推理： Reset 解除、lifecycle 資料有效、ROM check 完成，以及 CPU 或 debug 接受請求是不同事件。單一 ready bit 不能代替全部條件。
- 比較：為什麼 reset deassertion 要在各目的域同步，而多位元 lifecycle 值要用 handshake？ 推理： 各域的 reset synchronizer 控制本地解除時序。Handshake 或穩定編碼則維持多個資料位元之間的關係。
- 情境：沿共用教學事件順序，permission 先到目的域；來源 check_done 後來才完成，且尚未同步到 clk_dbg。debug_accept 應如何處理？ 推理： 目的域觀察到前提之前，debug_accept 必須維持低。弱政策若先接受 permission，就是反例。
- 故障診斷：lifecycle bus 每個 bit 各自通過 synchronizer，可能出現什麼問題？ 推理： 不同 bit 可能在不同週期到達，組合成來源端從未送出的值。應使用一致的傳輸協定或穩定保持的編碼。
- 設計風險／轉移：producer 重啟時，consumer 和 FIFO 仍在運作。Review 必須先釐清什麼？ 推理： 定義哪些 reset groups 可以獨立重啟、在途資料要清除或排空，以及哪些 transaction 仍有效。CDC/RDC 結構報告本身不能證明政策正確。
延伸閱讀
OpenTitan Lifecycle Controller
MY ACADEMY · LESSON FILM
教學影片
影片依序說明本課的資料路徑。看完一段，可以回到下面的互動練習，改變輸入或故障條件。動畫呈現教學模型；它沒有替代 RTL 模擬。
左右滑動影片，或用方向鍵查看圖卡。
圖卡的範圍說明
教學模型 · 非 RTL 模擬或晶片實測
共同教學時間線；不是跨域週期比較、亞穩態機率或 STA 結果
旁白使用合成聲音。互動教學與動畫均有模型邊界；請以本課的來源與驗證範圍解讀結果。
Wrap-up｜把這一課帶回設計審查
- 威脅模型與成立條件
啟動期間，debug permission 與 ROM check_done 分屬不同時脈域；目的域 reset 解除後，可能先看到 permission，還沒同步到 check_done。
- 失效原因
目的域在 synchronized check_done 前接受 debug permission；不同 reset release 與時脈相位可讓這條路徑先到。
- 防護方法
在每個域同步解除 reset，以握手傳遞 lifecycle/check 狀態，接受端就地檢查穩定條件。
- 驗證方式與待做檢查
相位與狀態交叉列舉、CDC/RDC 結構檢查、時序與正向啟動控制；本課尚未執行 RTL/formal/STA。
- 防護界線與未驗證項目
緣模型不代表亞穩態機率、類比電源、真實 reset tree 或實體生命週期熔絲。
換個情境再想一次
改變目的域頻率並加入一個跨域 FIFO。定義哪些 reset 分組可獨立重啟，並提出接受端需要的最小證據。
以上整理對照本課的教學案例、參考資料與實驗範圍；未列為已完成的驗證，都是後續工作。