MCTP over I3C沒有Response
問題真的出在MCTP嗎？
隨著伺服器架構日益複雜，SSD、電源控制器、溫度感測器、加速器與記憶體模組等元件，都需要進行狀態監控、韌體更新、組態設定及異常通知，MCTP提供標準化的管理訊息架構與定址機制，但MCTP本身並不負責實際的電氣訊號傳輸，而是透過PCIe、SMBus、I3C等介面作為傳輸層。其中，I3C 具備12.5 MHz傳輸速率、Dynamic Address Assignment(DAA)及In-Band Interrupt(IBI)等特性，逐漸成為新一代平台管理架構中重要的傳輸介面。但當MCTP與I3C結合之後，系統除錯也變得更加複雜。
一個沒有Response的問題，可能來自三個不同層級
MCTP over I3C 必須依照一定的順序完成初始化與通訊。首先由I3C完成 DAA，讓裝置取得Dynamic Address，接著進行MCTP Bus Initialization，為裝置配置Endpoint ID(EID)。完成初始化後，Controller可透過I3C Private Write傳送MCTP Message，當Target有資料需要回傳時，可利用IBI通知Controller，再由Controller透過Private Read取得資料。因此，一筆看似簡單的MCTP通訊，背後其實同時牽涉：
I3C Transport → MCTP Messaging → Application Protocol
任何一層發生異常，都可能造成相同的結果，「Command 送出去了，為什麼沒有 Response？」問題不一定出現在你看到症狀的那一層。
第一層：I3C發生問題，MCTP甚至還沒真正開始
🔸DAA Failure
在MCTP Endpoint Discovery開始之前，每個裝置都必須先取得有效的I3C Dynamic Address。如果DAA沒有正確完成，後續MCTP Initialization也無法正常進行。
🔸IBI未正確Enable
Target有資料需要回傳時，可透過IBI通知Controller。如果Controller沒有正確Enable IBI，即使Target已經準備好Response，Controller仍可能無法取得資料。
🔸PEC Error
MCTP over I3C Packet包含CRC-8 PEC，用來進行錯誤偵測。當訊號完整性問題造成其中一個Bit發生錯誤，就可能導致PEC Failure，使Packet被丟棄。
若問題只是間歇性發生，工程師看到的現象甚至可能只是偶發性的Message Loss。
第二層：I3C正常，不代表MCTP一定正常
當即使裝置已經成功取得I3C Dynamic Address，MCTP仍然可能發生問題。
🔹EID Assignment Failure
I3C Dynamic Address與MCTP Endpoint ID 是兩套獨立的定址機制。裝置可能已經擁有正確的I3C Address，卻因為MCTP Initialization沒有完整執行，而沒有取得EID，甚至出現Duplicate EID。結果就是Message無法送達正確的Endpoint。
🔹Timeout & Retry
當Response超過規範所要求的時間，Sender可能重新執行Transaction。如果Bus狀況不佳，持續Retry會增加Bus Traffic，反而讓原始問題更難被辨識。
🔹Fragmentation & Reassembly Error
較大的MCTP Message必須拆分成多個Packet傳輸。如果其中一個Packet 遺失、順序錯誤或Sequence Number不正確，Receiver就可能無法重新組合完整Message。
第三層：Transport都正常，問題可能發生在Application
更麻煩的是，I3C正常、MCTP也正常，Command還是可能失敗。例如MCTP上層承載的NVMe-MI、SPDM、PLDM等管理協定，本身仍有各自的Protocol行為。
🔸Version Mismatch
Controller與Endpoint使用不相容的Protocol Version，可能直接造成Message被拒絕。
🔸NVMe-MI Command Rejection
MCTP Packet可能已經正確抵達Endpoint，但NVMe-MI Command本身不受支援、格式不正確，或是在錯誤的Controller State下送出。此時Transport Path完全正常，但Transaction依然失敗。
🔸SPDM Authentication Failure
Certificate Exchange、Timeout或Algorithm不匹配，都可能造成Authentication Failure，使Endpoint被視為Untrusted，進而停止後續通訊。
為什麼MCTP over I3C特別難Debug？
因為不同層級的問題，最後可能呈現完全相同的症狀。例如：
「NVMe-MI Command沒有收到Response」
真正的原因可能是，DAA Failure → I3C Layer，也可能是，EID不正確 → MCTP Layer，甚至可能只是，Packet Loss / PEC Error → Transport，或者，NVMe-MI Command被拒絕 → Application Layer
如果只能看到單一Protocol Layer，就必須逐層排除問題，才能找出真正的Root Cause。而部分問題又只會在長時間傳輸、特定Power State Transition或較高Bus Loading 下偶發出現，使除錯更加困難。
Debug MCTP over I3C，需要同時看到三個Protocol Layer
有效分析MCTP over I3C，關鍵並不只是看到I3C Traffic，而是能夠將不同層級的資訊放在同一個時間軸上進行關聯分析。Prodigy Technovations PGY-I3C-EX-PD將Protocol Analyzer與Exerciser整合於同一平台，針對MCTP over I3C提供跨層驗證與除錯能力。
Analyzer可進行MCTP over I3C Decode，包括Message Type、Endpoint Addressing、Multi-Packet Reassembly及Error Detection，並進一步解析NVMe-MI｜SPDM｜PLDM，所有資訊皆可與I3C Timing Diagram進行關聯，協助工程師確認問題究竟發生在哪一個Protocol Layer。
但「看見問題」只是第一步。PGY-I3C-EX-PD同時具備Exerciser功能，可產生Scripted MCTP Traffic，以已知且可控制的行為模擬系統其中一端。例如NVMe-MI Command沒有收到Response時，可利用Exerciser取代Controller，重新送出相同的Command Sequence，如果Endpoint正常回應，問題可能位於原本的Controller，如果依然沒有回應，則可以進一步將分析集中在Endpoint。透過這種方式，可更有效率地隔離問題來源。
當下一次遇到「Command 沒有 Response」時，不必再從不同工具與Protocol Layer逐一猜測問題。一次看清完整Protocol Stack，更快從Symptom找到Root Cause。歡迎聯繫我們，進一步了解MCTP over I3C Protocol Validation與PGY-I3C-EX-PD測試方案。
專注誠芯，成就技術