（Electronics × Comms = “你以為是協定，其實是硬體在拖累”）
— 通訊系統最常見的誤判是：誤碼率、掉速、延遲抖動、斷線看起來像「協定/軟體問題」，但根因往往是：SI/PI/Clock/EMI/熱/電源噪聲把「可用 SNR」吃掉了。真正的通訊工程，必須把電子設計的物理限制納入鏈路預算與系統 KPI。
🎯 單元目標
完成本單元後，你將能夠：
• 用一條統一因果鏈把 PDN → Clock → SI → EMI → RF 前端 → 協定效能串起來
• 建立通訊性能的三個硬體 KPI：可用 SNR、可用 Eye、可用 Time Budget
• 看懂常見“通訊性能退化劇本”：吞吐下降 → 重傳變多 → 延遲抖動變大 → 斷線
• 用 ASCII 心像圖快速判斷：你缺的是 SNR、眼圖、時脈、供電穩定哪一個
• 把策略落地：設計、量測、調參、監測、量產一致性
🧭 一、先給一句話總結（超核心）
👉 通訊性能 = 協定演算法 ×（硬體可提供的“乾淨度”）。電子設計決定雜訊底、時脈品質、前端線性度與干擾隔離，這些會直接改寫：BER、吞吐、延遲、連線穩定度。
🧠 二、統一框架：通訊 KPI 其實被 3 個硬體預算決定
你以後看任何通訊問題，都先對照這三個「硬體預算」：
2.1 可用 SNR（信噪比預算）
• 電源雜訊 → 進入 ADC/DAC、PLL、PA/LNA 偏壓 → 等效把噪聲抬高
• EMI/串擾/地彈 → 直接把干擾灌進接收端
• 熱 → 噪聲增加、增益漂移、PA 壓縮點下降
→ 結果：BER 上升、MCS 降階、吞吐下降
2.2 可用 Eye（眼圖/通道預算）
• SI 反射/ISI/損耗 → 眼圖閉合（垂直/水平都縮）
• 連接器/走線/過孔/Stub → 頻域出現凹點與相位畸變
→ 結果：FEC 壓力變大、重傳變多、延遲抖動上升
2.3 可用 Time Budget（時序/同步預算）
• Clock jitter/phase noise（PLL/REF/PDN 注入）
• SerDes CDR 壓力上升、鎖相邊界變窄
→ 結果：同步不穩、偶發掉鏈路、吞吐忽高忽低
ASCII（硬體三預算 → 通訊 KPI）
硬體乾淨度 → (SNR budget) → BER → MCS/吞吐
→ (Eye budget) → FEC/重傳 → 延遲/抖動
→ (Time budget) → 同步/鎖定 → 斷線/掉速
⚡ 三、把“電子設計”如何一路改寫“通訊性能”的因果鏈（你要背的只有這條）
👉 快邊緣 / 高頻化（dv/dt、di/dt、GHz/多通道）
→ PDN 壓力上升（droop/SSN）
→ PLL/時鐘被注入雜訊（jitter/phase noise ↑）
→ SerDes/ADC 門檻變不穩（sampling margin ↓）
→ SI 問題更敏感（反射/ISI/串擾更致命）
→ EMI/共模路徑被打開（機殼/線纜變天線）
→ 接收端等效噪聲上升（SNR ↓）
→ BER ↑ → FEC/重傳 ↑ → 吞吐 ↓、延遲抖動 ↑、斷線風險 ↑
ASCII（一條線看穿：硬體 → 協定 → KPI）
PDN雜訊 → jitter↑ → 取樣錯誤↑ → BER↑ → 重傳↑ → 吞吐↓ + 延遲抖動↑
SI劣化 → eye縮小 → FEC負擔↑ → 有效速率↓
EMI干擾 → SNR↓ → MCS降階 → 速率掉 + 斷線風險↑
熱/漂移 → 增益/門檻漂 → 邊界縮 → 偶發變必發
🧠 四、最典型的“通訊性能退化劇本”（硬體視角）
劇本 1：吞吐下降不是網路塞車，是 MCS 被迫降階
SNR ↓（電源雜訊/外部干擾/隔離不足）
→ BER ↑ → Link adaptation 自動降階（更保守的調變與編碼）
→ 你看到的就是“速度突然變慢”
劇本 2：延遲抖動變大不是程式慢，是重傳/FEC 在救火
眼圖變小（SI/串擾/接頭）
→ FEC 更常啟動、重傳上升
→ 平均延遲不一定爆，但 jitter 變超明顯（體感：卡頓）
劇本 3：偶發斷線不是玄學，是 clock/同步預算被吃光
PDN 雜訊或 EMI 注入 → PLL jitter 上升
→ CDR 鎖定邊界縮小
→ 某些 pattern/溫度/負載下就掉 lock
→ 你看到的就是“偶爾斷一下、又自動恢復”
劇本 4：量產尾巴機台特別爛，是通道/元件分佈在角落死亡
connector/線纜/板材批次差 + 公差疊加
→ 少數機台 SNR/Eye/Time budget 同時偏小
→ 你以為是軟體 bug，其實是統計尾巴
🧩 五、工程落地：把“電子設計”做成“通訊性能保證”的五件事
- 設計：先把硬體預算做厚（別只看典型值）
• PDN：把 Z(f) 壓低、隔離敏感 rail（PLL/ADC/RF bias） • Clock：低相位雜訊參考源、良好供電隔離與地回流 • SI：控阻抗/減 stub/正確終端/減串擾 • EMI：先堵共模路徑（回流、屏蔽、接地、線纜出口） • 熱：把溫度當成“通訊參數”，不是機構附帶問題 - 量測：用通訊 KPI 驗證硬體，而不是只看波形漂亮
• 量 BER/FER、重傳率、MCS 分佈、EVM（若是 RF） • 量眼圖開口、jitter、PDN droop 與頻譜 • 把量測對應回三預算：SNR / Eye / Time - 調參：協定調得再漂亮，也救不了硬體底噪
• 先修硬體預算（PDN/Clock/SI/EMI） • 再調協定參數（equalization、FEC、功率、通道配置） • 原則：先讓物理邊界變寬，再談演算法最佳化 - 監測：把退化變成可見訊號
• 監測：RSSI/SNR、MCS、重傳率、錯誤碼、掉線次數 • 同步監測：溫度、供電、clock lock 狀態 • 出現趨勢 → 降階/保護/提示維修（不要等到客訴爆炸） - 量產：一致性就是性能（性能不是平均，是尾巴）
• 關鍵料件控管：connector、線纜、去耦有效值、晶振品質 • 抽測策略：把“最敏感指標”納入規格（不是只過功能測試） • 現場回收數據閉環：用統計回推設計裕量
🛠️ 六、一張“通訊掉速/斷線 Debug 優先順序”（硬體人最實用）
- 先抓 PDN（特別是 PLL/ADC/RF bias rail）：droop/SSN 會放大一切問題
- 再抓 Clock/PLL（jitter/phase noise/lock）：時脈不乾淨，所有取樣都不可信
- 再抓 SI（通道/終端/過孔/Stub/串擾）：眼圖是吞吐與延遲的地基
- 再抓 EMI/共模路徑（線纜/機殼/接地）：干擾不是“加磁珠就好”，是路徑設計
- 最後才看協定與軟體參數：不然你會一直在“錯的層級”打補丁
🧪 SYSTEM 實驗題（113/120）
實驗名稱
硬體三預算對通訊 KPI 的映射：同一條鏈路下，分別注入 PDN 雜訊 / Clock jitter / 通道劣化，觀察 BER、MCS、吞吐與延遲抖動的變化（ASCII 強化版）
🎯 實驗目的
- 用可重現方式證明：掉速/卡頓/斷線常常是硬體預算被吃光
- 建立你自己的“快速判別法”：看到某種 KPI 變化，就知道該查哪個硬體預算
- 把通訊調參從“盲調”升級成“物理閉環”
🧰 器材（教學友善）
• 可控供電（可製造 droop/噪聲）
• 可控時脈源（或可調 jitter/替換晶振）
• 可控通道（加長線纜/加入 stub/插拔不同 connector）
• 示波器（看 PDN/Clock/SI）
• 通訊端 KPI 監測（BER/重傳率/MCS/吞吐/延遲抖動 log）
🔧 實驗架構與做法
A) 建 baseline：室溫 / 標準供電 / 標準通道
→ 記錄：BER≈0、MCS 高、吞吐穩、jitter 小、眼圖開
B) 注入 1：PDN 壓力測試（供電 droop 或疊加噪聲）
→ 觀察：PLL jitter 是否上升？BER 是否上升？MCS 是否降階？
→ 結論：PDN → Clock/SNR 的耦合強度
C) 注入 2：Clock 壓力測試（增加 jitter 或換較差參考源）
→ 觀察：同步是否變差？掉線是否變多？延遲抖動是否放大？
→ 結論：Time budget 的邊界在哪
D) 注入 3：通道劣化測試（線纜加長/增加 stub/換 connector）
→ 觀察：眼圖開口縮小→FEC/重傳上升→吞吐下降
→ 結論：Eye budget 如何映射到吞吐與 jitter
E) 修法：按 Debug 優先順序修
→ 先修 PDN/Clock，再修 SI/EMI
預期：
👉 BER 尾巴縮短、MCS 更穩、吞吐回升、延遲抖動下降、掉線變少
🧠 本單元統整
📡 電子設計決定通訊的下限與上限：PDN 決定時脈與前端乾淨度、Clock 決定取樣可信度、SI 決定眼圖與重傳壓力、EMI 決定可用 SNR；你把硬體三預算（SNR/Eye/Time）做厚，再談協定與演算法，通訊 KPI 才會“穩、快、長期不飄”。
