AI GPU 公司 L1 Junior Engineer 企業培訓知識點

________________________________________
AI GPU 公司 L1 Junior Engineer 企業培訓知識點
________________________________________
📘AI GPU 公司 L1（Junior Engineer）企業培訓手冊
適用對象：N3 / N2 / A16 專案工程師
________________________________________
第一篇｜L1 角色定位與專案責任
1. L1 定位與職責邊界
2. AI GPU 專案流程總覽
3. L1 在 SoC 流程中的位置
4. L1 的交付責任與簽核制度
________________________________________
第二篇｜RTL 設計基礎
5. RTL Coding 標準
6. FSM 設計實務
7. Pipeline 基礎
8. Stall / Hazard 基礎
9. Ready/Valid 協定
10. Arbitration 基礎
11. 可綜合 RTL 原則
12. 常見錯誤案例解析
________________________________________
第三篇｜DV 基礎能力
13. Testbench 架構
14. Basic UVM 概念
15. Assertion 基礎
16. Functional Coverage 概念
17. Regression 使用
18. Debug 方法論
19. Bug 分類與追蹤
________________________________________
第四篇｜品質與風險意識
20. Lint 與 Coding Review
21. CDC 基礎概念
22. Reset 策略
23. Timing 基礎
24. IR Drop 概念
25. 功耗基礎
26. Tape-out 風險意識
________________________________________
第五篇｜專案工作流程
27. 任務拆解方法
28. PRD 閱讀能力
29. Code Review 回應
30. 與 DV / PD 協作
31. Issue 管理系統
32. Bring-up 支援流程
________________________________________
第六篇｜成長與考核制度
33. L1 KPI
34. 12–24 月成長模型
35. 常見失敗案例
36. L2 晉升標準
37. 行為準則
38. 結語
________________________________________
📘 第一篇｜L1 角色定位與專案責任
第1章｜L1 定位與職責邊界
核心在於明確 L1 在 AI GPU 專案中的戰略定位與責任邊界。在 N3 / N2 / A16 等先進節點專案中，L1 並非「學習者」，而是能在規範內穩定交付成果的工程執行者。L1 的價值不在創新，而在於「不製造風險」。其三大核心目標為：Correctness（功能正確）、Stability（行為穩定）、Maintainability（可維護性）。在數千萬行 RTL、數百模組的 GPU SoC 中，一個小錯誤可能導致整體 delay，因此 L1 的穩定性等同專案可預測性。
此外，明確區分 L1 與 L2～L5 的責任差異：L1 不參與架構設計、不決策、不制定策略，但負責執行品質。其責任涵蓋 RTL 實作、基本 DV、Lint clean、無 warning 等。更重要的是，L1 不可跨越邊界（如 power domain、CDC、DFT 等），遇到問題必須升級回報。
亦強調風險意識：如 reset 遺漏、FSM default 缺失等小錯誤，可能導致矽上 hang 或隨機 crash。最後透過 Definition of Done（DoD）制度，建立交付標準：必須同時滿足 spec、lint、regression、review。總結而言，L1 是 AI GPU 專案的「地基層」，其穩定性直接決定整體工程品質與成本。
________________________________________
第2章｜AI GPU 專案流程總覽
從端到端視角說明 AI GPU 開發流程，使 L1 能理解自身工作在整體系統中的位置。完整流程包含：PRD → Architecture → Micro-architecture → RTL → DV → Synthesis → P&R → Signoff → Tape-out → Fabrication → Packaging → ATE → Burn-in → Bring-up → 量產。L1 主要位於 RTL 與 DV 階段，但影響可延伸至 signoff、bring-up 甚至出貨。
強調「小錯誤長延遲」效應：RTL 中的問題可能在數月後矽上爆發，因此 L1 必須理解整體流程，而非僅關注自身模組。特別是在 AI GPU 中，HBM、CoWoS、1.5kW 功耗等特性，使錯誤放大效應更強。
各階段也有關鍵知識要求：L1需能閱讀PRD、理解架構意圖、正確實作RTL、協助DV debug、理解timing與power影響。
此外，提出風險傳導鏈：
RTL bug → DV未覆蓋 → Tape-out → 矽上錯誤 → Stop-ship → 財務損失。
並強調流程紀律（review、regression、版本控管）不可被跳過。
結論是：AI GPU 是長週期、高資本專案，L1 每一行 RTL 都可能影響 IRR、SLA、Yield。因此理解全流程，是 L1 進入專業工程師的第一步。
________________________________________
第3章｜L1 在 SoC 流程中的位置
深入解析 L1 在 SoC 組織與設計流程中的實際位置。AI GPU SoC 屬於高度分工系統，包含數百工程師與長達18–30個月開發週期，因此角色邊界必須明確。L1 位於組織最底層，但其影響力不容忽視。
在技術分工上，Architecture 與 Micro-architecture 由 L3/L4 負責，L1 不參與設計，而是在 RTL 層進行模組實作，例如 FIFO、FSM、interface glue logic 等。同時在 DV 層支援 debug，但不負責整體 coverage 策略。
重點在於「影響路徑」概念：
不良 RTL → timing violation → P&R fail → tape-out delay
或
reset 錯誤 → 矽上 hang → bring-up 延誤
說明 L1 雖不決策，但會影響決策。
此外，L1 工作會向上流動（L2整合、L3風險管理），若品質不穩定，整體組織將被迫救火。
不同專案階段中，L1角色也不同（開發期→debug期→tape-out前穩定期→bring-up支援）。
結論：L1 是 SoC 工程體系的「穩定輸出節點」，其紀律與品質直接影響良率、SLA與客戶信任。
________________________________________
第4章｜L1 的交付責任與簽核制度
建立 L1 工程交付的制度化框架，是企業級專案管理的核心。AI GPU 專案因 Tape-out 成本高、週期長，必須透過嚴格簽核制度確保品質。
L1 的交付責任包含四大面向：功能正確、工程品質（Lint clean）、驗證完成度（無critical bug）、文件完整性。任何未驗證或含 TODO 的代碼均不得提交。
Definition of Done（DoD）被明確定義為：RTL完成 + Simulation通過 + Lint=0 + Regression clean + Code review通過 + 無critical issue。
簽核流程為：L1開發 → Self-check → Lint/Sim → L2 review → L2/L3批准 → merge。禁止 bypass 流程。
此外，強調 Code Review 重點（reset、FSM、latch、loop 等）與 regression 強制制度（不得帶 fail）。
風險升級機制也被明確規定：若遇 spec、CDC、timing 等問題，必須上報，不可自行 workaround。
最後建立責任追溯制度（commit log、bug ID）。
結論：簽核制度的本質不是限制，而是風險控制。L1 必須提供「可簽核、可追溯、可量產」的工程輸出。
________________________________________
📘 第二篇｜RTL 設計基礎
第5章｜RTL Coding 標準
定義 RTL coding 為 AI GPU 專案的「生死線」。在先進節點下，timing margin 小、功耗密度高，RTL 結構直接影響 P&R、power、yield。
三大核心原則：Deterministic（無未定義行為）、Synthesizable（可綜合）、Maintainable（可維護）。
具體規範包括：命名規則（_i/_o/_r）、reset 必須完整、blocking/non-blocking 正確使用。
嚴格禁止行為：latch inference、combinational loop、未覆蓋case、未reset FSM。
此外，強調 ready/valid、pipeline coding、註解規範與 lint 檢查。
透過實際案例（reset缺失、blocking錯誤、stall未處理）說明錯誤代價。
結論：RTL coding 不是風格問題，而是量產風險控制問題。
________________________________________
第6章｜FSM 設計實務
FSM 是控制路徑核心，錯誤會導致 deadlock、非法狀態或資料錯亂。
介紹 FSM 三大結構（state、next-state、output）與 encoding（one-hot vs binary）。
設計原則：必須有 reset state、default fallback、避免非法狀態。
特別強調 ready/valid FSM 與 stall/backpressure 控制。
常見錯誤：缺 default、未 reset、過度複雜導致 timing fail。
結論：FSM 穩定性 = 模組穩定性。
________________________________________
第7章｜Pipeline 基礎
Pipeline 是 AI GPU 高頻與高吞吐的核心。
透過 stage 切分降低 combinational delay，提高 frequency。
設計重點：stage劃分清晰、register reset、stall control。
介紹 hazard（RAW、structural、control）與常見錯誤（stall錯誤、data mismatch）。
強調 pipeline 與 timing、power、IR drop 關係。
結論：錯誤 pipeline 可能導致整顆晶片無法收斂。
________________________________________
第8章｜Stall / Hazard 基礎
說明 pipeline 中 stall 與 hazard 的風險。
stall=暫停更新，必須保持資料一致。
hazard 分為 RAW、structural、control。
強調 ready/valid 與 stall 關係。
常見錯誤：只 stall data、不 stall control、資料覆寫。
結論：此類錯誤屬於「隱性高風險」，最容易在矽上爆發。
________________________________________
第9章｜Ready / Valid 協定
Ready/Valid 是 AI GPU 資料流的核心協定。
核心公式：transfer = valid & ready。
規則：valid 由 source 控制，ready 由 sink 控制。
常見錯誤：valid依賴ready、deadlock、data loss。
強調 pipeline、backpressure、arbitration 與 timing影響。
結論：這是 L1 必須 100% 精通的基本功。
________________________________________
第10章｜Arbitration 基礎
Arbitration 解決多請求資源競爭問題。
介紹 fixed priority、round robin、weighted 三種方式。
設計原則：grant 必須 one-hot、對應有效 request。
常見錯誤：多 grant、starvation、stall 不一致。
強調 timing 與功耗影響。
結論：仲裁錯誤可能直接影響 GPU 吞吐與性能。
________________________________________
第11章｜可綜合 RTL 原則
核心在於建立「模擬 ≠ 綜合 ≠ 矽上」的正確認知，並強調所有 RTL 必須以量產可行性為第一優先。在 AI GPU 專案中，RTL 並非僅為功能描述，而是直接決定後續 synthesis、P&R、timing、功耗與 IR drop 表現的根本。許多工程師常誤以為模擬通過即代表設計正確，但實際上模擬僅為行為層級抽象，而綜合後會轉為邏輯閘結構，最終在矽上則呈現電氣特性，因此三者之間存在本質差異。
提出數個關鍵原則：第一，僅使用可綜合語法，例如禁止 #delay、fork/join、initial 等不被綜合工具支援的語法。第二，嚴格區分時序邏輯與組合邏輯，避免 latch inference。第三，所有 register 必須明確 reset，避免矽上隨機初始化導致不穩定。
此外，特別強調 combinational loop、multiple driver、X propagation 等問題，這些在模擬中可能未被察覺，但在實際設計中將造成致命風險。
結論是：L1 在撰寫 RTL 時，必須以「電路實現」思維取代「程式語言」思維。唯有具備可綜合性，RTL 才能進入量產階段。
________________________________________
第12章｜常見錯誤案例解析
透過實際專案案例，建立 L1 對錯誤風險的敏感度。在 AI GPU 專案中，多數重大問題並非來自複雜架構，而是基礎 RTL 錯誤，例如 reset 不完整、latch inference、blocking/non-blocking 混用等。這些錯誤在模擬中往往不易顯現，但在高壓測試或矽上環境中會被放大。
例如未完整 reset 的案例，在模擬中可能正常，但在矽上會產生隨機初始狀態，導致 bring-up hang；又如 ready/valid 設計錯誤，可能造成 deadlock，使整個系統停滯。stall 控制不當則會導致資料覆寫，形成難以重現的 intermittent bug。
也分析 combinational loop、multi-driver、illegal FSM state 等問題，這些錯誤將直接影響 synthesis 與 timing closure，甚至導致整個 tape-out 延誤。
透過這些案例，L1 應建立一套自我檢查機制，包括：是否完整 reset、是否存在 latch、是否遵守協定、是否通過 lint 與 regression。
結論：錯誤不可怕，但忽略錯誤才是最大風險。工程紀律是 AI GPU 專案成功的關鍵。
________________________________________
📘 第三篇｜DV 基礎能力
第13章｜Testbench 架構
說明 DV（Design Verification）中 Testbench 的基本架構與運作方式。RTL 設計完成並不代表任務完成，只有經過完整驗證的 RTL 才具備 tape-out 條件。標準 testbench 架構包含 stimulus generator、driver、DUT、monitor、checker（scoreboard）與 coverage collector。
L1 雖不需設計完整驗證架構，但必須理解各模組角色，並能撰寫基本 testbench。例如透過 stimulus 驅動 DUT，並透過 monitor 收集輸出，再由 checker 比對預期結果。
強調，測試不應只驗證「不 crash」，而應確認「結果正確」。此外，functional coverage 是驗證完整度的重要指標，不能只測試 happy path，必須涵蓋 corner case、reset 行為與 stall 情境。
常見錯誤包括未測試 reset、未考慮 backpressure、未覆蓋 FSM 所有狀態等。
結論：Testbench 是 RTL 的安全網，L1 必須具備基本 DV 能力，確保設計在 tape-out 前已被充分驗證。
________________________________________
第14章｜Basic UVM 概念
介紹 UVM（Universal Verification Methodology）的基本架構與核心理念。在 AI GPU 專案中，由於模組數量龐大且驗證需求複雜，傳統 testbench 已無法支撐，因此導入 UVM 進行模組化與可重用設計。
UVM 架構包含 test、environment、agent、driver、monitor、scoreboard 等組件，其中 transaction 為資料傳遞單位。L1 不需設計完整 UVM 架構，但必須理解其運作原理，並能閱讀與修改既有驗證環境。
也介紹 randomization 與 coverage-driven verification 概念，透過 constrained random 測試，提高 corner case 覆蓋率。
此外，UVM phase 機制負責控制模擬流程，使測試能有系統地執行。
結論：UVM 是大型 SoC 驗證的標準方法論，L1 必須具備基本理解能力，以支援 DV 團隊並提升驗證效率。
________________________________________
第15章｜Assertion 基礎
Assertion（斷言）是用於檢查設計行為是否符合規範的重要工具。介紹 assertion 在 RTL 與 DV 中的應用價值。透過 assertion，可在模擬過程中即時檢測錯誤，而非等待最終結果比對。
常見 assertion 類型包括：protocol assertion（如 ready/valid）、FSM state 合法性、timing constraint 等。L1 應能撰寫基本 assertion，例如檢查 valid 與 ready 的關係，或確保 FSM 不進入非法狀態。
Assertion 的優勢在於：能快速定位錯誤來源，縮短 debug 時間，並提高驗證完整性。
然而，錯誤使用 assertion（如條件不完整或誤判）也可能導致 false alarm，因此需謹慎設計。
結論：Assertion 是提升設計品質與驗證效率的重要工具，L1 應逐步建立使用能力。
________________________________________
第16章｜Functional Coverage 概念
Functional Coverage 用於衡量驗證是否涵蓋所有設計行為。說明 coverage 的重要性與基本概念。在 AI GPU 專案中，僅依靠測試通過無法保證設計正確，必須透過 coverage 確認所有狀態與情境均被驗證。
Coverage 可分為 code coverage（語句覆蓋）與 functional coverage（功能覆蓋），其中後者更重要。L1 雖不需設計完整 coverage model，但必須理解其意義，並確保基本測試能覆蓋所有 FSM 狀態與主要操作情境。
常見問題包括 coverage 未達標、測試偏向特定情境、忽略 corner case 等。
結論：Coverage 是驗證品質的量化指標，L1 必須具備基本認知，避免「測試通過但設計不完整」的風險。
________________________________________
第17章｜Regression 使用
Regression 是指自動化測試集合，用於確保設計修改不會破壞既有功能。說明 regression 在 AI GPU 專案中的重要性。
L1 每次提交代碼後，必須確保 regression 全部通過，否則不得 merge。Regression 可快速檢測新修改是否引入 bug，並維持設計穩定性。
強調 regression 的三大原則：完整性（涵蓋所有測試）、即時性（每日執行）、可追溯性（記錄失敗原因）。
常見錯誤包括忽略 regression fail、未分析失敗原因、或僅修正表面問題。
結論：Regression 是品質保證機制，L1 必須將其視為日常工作的一部分，而非額外負擔。
________________________________________
第18章｜Debug 方法論
Debug 是 L1 最重要的能力之一。介紹系統化 debug 方法，包括從 waveform 分析、信號追蹤到 root cause 判斷。
核心原則是「找第一個錯誤點」，而非最後的錯誤現象。透過觀察 valid/ready、FSM state、data path，可逐步縮小問題範圍。
也強調 debug 紀律，例如記錄問題、重現 bug、避免盲目修改。
常見錯誤包括：直接修改代碼未理解原因、忽略邊界條件、或未確認問題是否完全解決。
結論：Debug 能力直接影響工程效率與專案進度，是 L1 成長的關鍵技能。
________________________________________
第19章｜Bug 分類與追蹤
介紹 bug 的分類與追蹤機制。在 AI GPU 專案中，bug 不僅是技術問題，更是管理問題。
Bug 可分為 functional bug、timing bug、integration bug 等，不同類型需不同處理方式。
所有 bug 必須記錄於 issue tracking system，並標註優先級、影響範圍與負責人。
L1 的責任包括：準確描述問題、提供重現步驟、追蹤修復進度。
強調透明與紀律，禁止隱藏或忽略 bug。
結論：有效的 bug 管理是專案成功的重要因素，L1 必須養成良好習慣。
________________________________________
第20章｜Lint 與 Coding Review
說明 lint 與 code review 在品質控制中的角色。Lint 工具可自動檢測 RTL 中的潛在問題，如未使用信號、latch inference、語法錯誤等。L1 必須確保 lint=0 violation。
Code review 則由 L2/L3 進行，重點檢查 reset、FSM、timing、協定遵守等。L1 必須認真回應 review 意見，不可忽略或情緒化。
強調 lint 與 review 是防止問題進入後續流程的第一道防線。
結論：良好的 coding discipline 能大幅降低 DV、P&R、tape-out 風險，是 L1 必備能力。
________________________________________
📘 第四篇｜品質與風險意識
第21章｜CDC 基礎概念
Clock Domain Crossing（CDC）是 AI GPU SoC 設計中極高風險的問題之一。核心在於讓 L1 理解不同 clock domain 之間資料傳輸所帶來的不確定性。當訊號從一個 clock domain 傳至另一個 domain 時，若未經適當同步，將可能產生 metastability（亞穩態），導致隨機錯誤或 intermittent failure。這類問題在模擬中極難捕捉，但在矽上可能頻繁發生，因此 CDC 被視為 tape-out 前必須嚴格控制的風險項。
介紹基本 CDC 類型，包括單 bit 控制訊號同步（通常使用兩級 flip-flop synchronizer）、多 bit 資料傳輸（需搭配 handshake 或 FIFO）、以及 async FIFO 等方法。L1 不需設計 CDC 架構，但必須能辨識 CDC 路徑，並避免直接跨 domain 使用未同步訊號。
此外，強調 CDC 工具檢查（如 SpyGlass CDC）與設計規範的重要性。常見錯誤包括：未同步 control signal、跨 domain combinational path、或錯誤使用 reset。
結論：CDC 問題屬於「低機率高災難」風險，一旦發生將難以 debug。L1 必須具備基本識別能力，並在發現問題時立即升級處理，而非自行修改設計。
________________________________________
第22章｜Reset 策略
Reset 是確保系統初始化穩定的關鍵機制，說明 reset 設計在 AI GPU 專案中的重要性。由於 GPU 屬於高複雜度系統，包含多個 clock domain 與 power domain，reset 若設計不當，將導致系統無法正常啟動或產生隨機錯誤。
區分同步 reset（synchronous reset）與非同步 reset（asynchronous reset），並說明其優缺點。同步 reset 易於 timing closure，但需依賴 clock；非同步 reset 可快速初始化，但需注意 deassertion timing。
L1 必須確保所有 register 皆有明確 reset 行為，且符合系統規範。常見錯誤包括：部分 register 未 reset、reset 順序錯誤、或依賴模擬 initial 值。這些問題在模擬中可能不明顯，但在矽上會導致不可預期行為。
此外，強調 reset tree 與 reset domain 的概念，說明 reset 本身也可能涉及 CDC 問題。
結論：Reset 並非單純初始化動作，而是整個系統穩定性的基礎。L1 必須以「矽上行為」為導向設計 reset，而非僅滿足模擬需求。
________________________________________
第23章｜Timing 基礎
Timing 是影響 AI GPU 是否能達到目標頻率的核心因素。提供 L1 必須理解的基本 timing 概念，包括 setup time、hold time、clock skew、以及 critical path。
在先進製程（N3 / N2 / A16）下，timing margin 極小，任何 combinational path 過長都可能導致 timing violation。RTL 設計直接影響 synthesis 與 P&R 的結果，因此 L1 雖不負責 timing closure，但必須理解 RTL 與 timing 的關聯。
說明如何避免產生過長 combinational path，例如減少巢狀條件、避免過大 fan-in/fan-out、以及適當使用 pipeline。常見錯誤包括：複雜 FSM decode、未分段運算、或過多比較器串接。
此外，強調 timing 報告（STA report）的基本閱讀能力，使 L1 能理解設計問題來源。
結論：Timing 問題往往源自 RTL 結構，而非後段工具。L1 必須具備基本 timing 意識，避免在設計初期引入難以修復的問題。
________________________________________
第24章｜IR Drop 概念
IR Drop（電壓降）是高功耗 AI GPU 設計中的關鍵挑戰之一。說明電流流經電源網路時產生的電壓損失，及其對晶片穩定性的影響。在現代 GPU（功耗可達 1kW 以上）中，IR drop 可能導致局部電壓下降，使電路無法正常運作，甚至產生 timing error。
介紹 IR drop 的兩種類型：static IR drop（平均負載造成）與 dynamic IR drop（瞬間 switching 導致）。L1 雖不設計 power grid，但其 RTL 行為（如 switching activity）會直接影響 IR drop。
例如過多 glitch、無效切換或高頻控制信號，都可能增加電流波動，進而加劇 IR drop。
此外，說明 IR drop 與 EM（電遷移）的關聯，指出長期高電流會影響可靠度。
結論：IR drop 並非後段問題，而是設計與實作共同影響的結果。L1 必須避免不必要的 switching，並理解功耗與電壓穩定之間的關係。
________________________________________
第25章｜功耗基礎
介紹 AI GPU 設計中的功耗基本概念，包括 dynamic power（動態功耗）與 leakage power（靜態功耗）。動態功耗主要來自 switching activity，而靜態功耗則來自晶體管漏電。在先進節點下，兩者皆不可忽視。
功耗計算基本公式為：Power ≈ C × V² × f × switching activity。L1 雖不需進行完整 power modeling，但必須理解 RTL 行為如何影響 switching activity。例如頻繁 toggling 的信號、無效資料傳輸、或過度複雜控制邏輯，都會增加功耗。
也介紹 clock gating、power gating 等基本概念，說明如何降低功耗。雖然這些策略通常由高階工程師設計，但 L1 必須確保其 RTL 不會破壞既有節能機制。
常見錯誤包括：未關閉無用模組、valid 信號過度切換、或 pipeline 無效運作。
結論：功耗直接影響 AI GPU 的性能與可靠度，甚至影響資料中心電力成本。L1 必須建立基本功耗意識，在設計中避免不必要的能源浪費。
________________________________________
第26章｜Tape-out 風險意識
Tape-out 是 AI GPU 專案中最關鍵且不可逆的階段，一旦設計送交製造，任何錯誤都將帶來巨大的時間與金錢成本。核心在於建立 L1 對 tape-out 風險的深刻認知。在先進節點（N3 / N2 / A16）下，一次 tape-out 成本動輒數千萬美元，且需等待數月才能取得矽樣，因此任何 RTL 錯誤都可能導致整個專案延誤一季以上。
強調「tape-out 前最後防線」的概念，包括 lint clean、regression 完整通過、無未解 critical bug、timing 與功耗 signoff 完成等。L1 雖不直接參與最終決策，但其負責模組的穩定性將直接影響整體風險。
此外，介紹常見 tape-out 失敗案例，例如未初始化信號導致矽上 hang、CDC 問題造成隨機錯誤、或 timing violation 導致頻率不達標。這些問題在模擬中可能難以發現，但在實際運作中會被放大。
結論：Tape-out 不是「完成設計」，而是「鎖定風險」。L1 必須以量產標準檢視每一行 RTL，確保其模組不成為整體專案的風險來源。
________________________________________
📘 第五篇｜專案工作流程
第27章｜任務拆解方法
說明 L1 如何將複雜設計任務拆解為可執行的小單位。在 AI GPU 專案中，任務通常來自 L2/L3 的模組分配，若未經良好拆解，將導致開發效率低落與風險增加。
任務拆解的核心在於將大問題分解為多個可驗證、可交付的小任務，例如：RTL 模組實作、testbench 撰寫、bug 修復等。每個子任務需具備明確輸入（spec）、輸出（code）、以及驗證方式（simulation）。
也強調時間管理與優先級排序，L1 應優先處理 critical path 任務，避免影響整體專案進度。
常見錯誤包括：任務過大導致無法驗證、未定義完成標準、或忽略依賴關係。
此外，介紹與 issue tracking 系統結合的方法，使任務具備可追蹤性與可管理性。
結論：良好的任務拆解能力能提升開發效率並降低風險，是 L1 成長為 L2 的重要能力之一。
________________________________________
第28章｜PRD 閱讀能力
PRD（Product Requirement Document）是 AI GPU 設計的起點，強調 L1 必須具備基本閱讀與理解 PRD 的能力。雖然 L1 不負責撰寫 PRD，但其 RTL 設計必須完全符合規格，否則將導致功能錯誤或驗證失敗。
PRD 通常包含性能指標（如 TFLOPS、bandwidth）、功耗限制、介面規格與功能需求。L1 必須能從中提取與自身模組相關的資訊，例如 input/output 定義、時序要求與錯誤處理機制。
也說明如何將 PRD 轉換為 RTL 設計，例如將功能描述轉為 FSM 或 datapath，並確保所有條件皆被實現。
常見錯誤包括：誤解 spec、忽略邊界條件、或未同步更新設計。
此外，強調與 L2/L3 溝通的重要性，當 PRD 不清楚時，必須主動確認，而非自行假設。
結論：PRD 是設計的唯一依據，L1 必須具備精確理解能力，確保設計符合產品需求。
________________________________________
第29章｜Code Review 回應
Code Review 是確保 RTL 品質的重要機制，聚焦於 L1 如何正確回應 review 意見。在 AI GPU 專案中，review 不僅是檢查錯誤，更是知識傳承與品質控制的關鍵流程。
L1 必須以開放態度接受 review 意見，並逐條回應，而非僅修正部分問題。回應應具體說明修改內容或解釋設計理由，確保 reviewer 理解變更。
強調常見 review 重點，包括 reset 是否完整、FSM 是否安全、是否存在 latch、ready/valid 是否正確等。
常見錯誤包括：忽略 review comment、情緒化回應、或未完全解決問題。
此外，說明 review 的目的是降低風險，而非批評個人，L1 應將其視為提升能力的機會。
結論：良好的 review 回應能力不僅提升代碼品質，也有助於建立團隊信任與專業形象。
________________________________________
第30章｜與 DV / PD 協作
說明 L1 在跨部門協作中的角色，特別是與 DV（Design Verification）與 PD（Physical Design）團隊的合作。在 AI GPU 專案中，各部門高度依賴，任何一方的問題都可能影響整體進度。
與 DV 協作時，L1 需快速回應 bug、提供修正版本，並協助 debug。理解 testbench 與驗證環境，有助於提高溝通效率。
與 PD 協作時，L1 雖不直接操作工具，但其 RTL 設計會影響 timing、power 與 IR drop。因此，當 PD 發現 timing violation 或 congestion 問題時，L1 必須配合修改 RTL。
強調溝通的重要性，包括清楚描述問題、提供 waveform、以及快速回應。
常見錯誤包括：推卸責任、回應不及時、或未理解問題本質。
結論：AI GPU 專案是團隊合作的成果，L1 必須具備良好協作能力，才能確保專案順利推進。
________________________________________
第31章｜Issue 管理系統
說明 Issue 管理系統在 AI GPU 專案中的核心角色。在大型 SoC 專案中，同時存在數百甚至上千個 bug、feature request 與改動需求，若無系統化管理，將導致問題遺漏、責任不清與進度失控。
Issue 管理系統（如 Jira、Bugzilla）提供標準化流程，包含問題建立、分類、優先級設定、指派負責人與狀態追蹤。L1 必須熟悉如何建立 issue，內容需包含：問題描述、重現步驟、影響範圍、log 或 waveform 證據。
強調 bug 分級的重要性，例如 critical（影響 tape-out）、major（影響功能）、minor（不影響主流程）。L1 應優先處理高優先級問題，確保專案進度。
常見錯誤包括：描述不清、未提供重現方式、或未更新狀態，導致團隊溝通成本增加。
此外，說明 issue lifecycle（open → assigned → fix → verify → close），確保問題完整解決。
結論：Issue 管理系統是專案運作的神經系統，L1 必須建立良好紀律，使問題可追蹤、可管理、可關閉。
________________________________________
第32章｜Bring-up 支援流程
Bring-up 是晶片回片後的第一個關鍵階段，介紹 L1 在此階段的支援角色。當矽樣返回後，團隊需驗證晶片是否符合設計預期，包括功能、頻率與功耗。
L1 雖非 bring-up 主導者，但必須快速支援問題分析。常見 bring-up 問題包括：系統無法啟動、功能異常、頻率不達標或功耗異常。這些問題往往與 RTL 設計有關，例如 reset 不完整、FSM 錯誤或 CDC 問題。
強調 debug 流程：從現象分析 → waveform 比對 → RTL trace → 找出 root cause。L1 必須能快速理解問題並提供修正方案。
此外，bring-up 階段時間壓力極大，任何延誤都會影響量產時程，因此回應速度與準確性同樣重要。
常見錯誤包括：無法重現問題、錯誤判斷 root cause、或修改後未完整驗證。
結論：Bring-up 是設計驗證的最終考驗，L1 的快速反應與問題解決能力，直接影響專案成功與否。
________________________________________
📘 第六篇｜成長與考核制度
第33章｜L1 KPI
定義 L1 的績效評估指標（KPI），用於衡量工程師的專業能力與貢獻。在 AI GPU 專案中，KPI 不僅反映個人表現，也影響團隊整體效率與品質。
L1 的主要 KPI 包括：
1️⃣ Code Quality（代碼品質）：Lint=0、無 warning、結構清晰
2️⃣ Bug Rate（錯誤率）：低錯誤率與快速修復能力
3️⃣ Delivery（交付能力）：按時完成任務並符合 DoD
4️⃣ Regression Stability：提交後不破壞 regression
5️⃣ Collaboration（協作能力）：與 DV、PD 團隊良好互動
強調 KPI 的本質在於「穩定輸出」，而非短期效率。即使開發速度快，但若錯誤率高，反而增加整體成本。
此外，介紹 KPI 與晉升的關聯，說明持續穩定表現是晉升 L2 的基礎。
結論：KPI 是衡量專業能力的量化工具，L1 應以品質與穩定為核心目標，而非僅追求速度。
________________________________________
第34章｜12–24 月成長模型
描述 L1 在 12–24 個月內的成長路徑，作為職涯發展指引。AI GPU 專案要求高專業能力，因此工程師必須有明確的學習與成長計畫。
成長分為三個階段：
第一階段（0–6 個月）：熟悉流程與工具，能完成基本 RTL 與 DV 任務。
第二階段（6–12 個月）：提升設計品質與 debug 能力，能獨立處理模組問題。
第三階段（12–24 個月）：具備子系統理解能力，能與 L2 協作並參與設計優化。
強調學習重點，包括 RTL 設計、verification、timing 與 power 基礎，以及跨部門溝通能力。
常見失敗原因包括：只專注單一技能、缺乏主動學習、或忽略工程紀律。
結論：成長不是自動發生，而是需要持續投入與反思。L1 應以成為 L2 為目標，逐步提升技術與責任範圍。
________________________________________
第35章｜常見失敗案例
總結 L1 在 AI GPU 專案中常見的失敗模式，並提供警示與學習方向。
常見失敗類型包括：
1️⃣ 忽略基本規範：未 reset、未處理 default，導致矽上錯誤
2️⃣ 缺乏紀律：跳過 review、忽略 regression
3️⃣ Debug 能力不足：無法定位問題或只修表面
4️⃣ 溝通不良：未回報問題或描述不清
5️⃣ 心態問題：抗拒 review、忽略建議
透過實際案例說明，這些問題如何導致專案延誤或成本增加。例如一個未處理的 ready/valid bug，可能導致系統 deadlock，進而觸發 stop-ship。
此外，強調「小錯誤大影響」的概念，在 AI GPU 專案中，任何細節都可能被放大。
結論：失敗並不可怕，但必須從中學習。L1 應建立風險意識與工程紀律，避免重複相同錯誤，並持續提升專業能力。
________________________________________
Chapter 36｜L2 晉升標準
L2（Subsystem Owner）代表工程師已從「任務執行者（L1）」進化為「模組負責人」，其核心標準在於自主性、系統理解與風險承擔能力。L1 的主要工作是依照既定規格完成 RTL、修正 bug、支援 DV，而 L2 則需能在 spec 不完整或模糊的情況下，主動拆解需求、定義設計邊界，並對模組行為負最終責任。這意味著 L2 必須具備完整的 debug 方法論，能從 regression fail、waveform、log 中快速定位 root cause，而不是依賴他人指導。
在技術能力上，L2 必須理解整個 subsystem 的 data flow、control flow、timing 影響、CDC/Reset 結構與 power 行為，並能與 DV、PD、DFT 團隊進行有效協作。例如，當 PD 回報 timing fail，L2 不僅能判斷是否為 RTL 結構問題，還能提出具體優化策略（pipeline、拆 logic、調整 fan-out）。此外，L2 需能建立基本驗證策略（test plan / coverage），確保模組在 tape-out 前達到可接受風險。
從組織角度來看，L2 也是「責任節點（Accountability Owner）」。當 subsystem 出現問題，L2 必須能整合資訊、對上回報、對下指導 L1，並在必要時參與 Stop-Ship 討論。因此，晉升 L2 的關鍵不在於寫了多少 RTL，而在於是否具備「獨立負責一個模組並承擔結果」的能力。
________________________________________
Chapter 37｜行為準則
在 AI GPU 等大型 SoC 專案中，技術能力固然重要，但**工程行為準則（Engineering Discipline）**往往是決定專案成敗的關鍵。行為準則的核心在於三點：誠信（Integrity）、透明（Transparency）、紀律（Discipline）。誠信代表工程師必須如實回報問題，不隱瞞 bug、不掩蓋風險；透明代表所有設計決策、問題狀態與風險資訊應可被團隊理解與追蹤；紀律則體現在遵守 lint、code review、regression、issue tracking 等流程，不因時間壓力而跳步。
在實務中，違反行為準則的情況非常常見，例如：為了趕進度忽略 lint warning、未回應 code review comment、發現 bug 卻延後回報、或在 regression fail 時仍強行 merge。這些行為短期看似提高效率，但長期會導致 bug 累積、debug 成本暴增，甚至在 tape-out 或 bring-up 階段爆發，造成不可挽回的損失。因此，成熟的工程師會主動維持流程品質，即使在高壓環境下仍堅持基本紀律。
此外，良好的行為準則也包含「責任感與協作精神」。當 DV 或 PD 遇到問題時，RTL 工程師不應以「不是我負責」為由拒絕支援，而應從系統角度協助分析與解決。AI GPU 專案本質是跨團隊合作，任何一個環節的問題都可能影響整體。因此，行為準則不只是個人品德問題，更是整個工程體系穩定運作的基礎。
________________________________________
Chapter 38｜結語
L1 到 L2 的成長，不只是技術能力的提升，更是思維模式的轉變。L1 的任務是「把事情做對（Do Things Right）」，而進入更高層級後，工程師需要開始思考「做對的事情（Do the Right Things）」。這代表從單一模組的正確性，擴展到整個 subsystem、甚至整個 SoC 的風險與效能平衡。
在 AI GPU 設計中，系統複雜度極高，涉及數百個模組、數千萬行 RTL，以及跨製程（N3/N2/A16）、封裝（CoWoS）、記憶體（HBM）與電力架構的整合。任何一個小錯誤，都可能在 tape-out 後轉化為數千萬美元的損失。因此，工程師必須建立「系統級思維」，理解自己的工作如何影響 downstream（DV、PD、SI、System、客戶端），並在每一次設計與決策中考慮風險。
最終，一名優秀的工程師，不只是能寫出正確的 RTL，而是能在不確定環境中做出正確判斷、在壓力下維持工程紀律、並持續提升自身能力。這也是從 L1 走向 L2、L3，甚至 L4/L5 的必經之路。當工程師能同時掌握技術深度、系統視野與決策能力時，才真正具備在 AI GPU 產業中長期發展的競爭力。
________________________________________