MCTP規範是由(DMTF)發佈，廣泛應用於許多電腦與伺服器架構中，因其定義了系統管理控制器(management controller)如何與受控裝置(如PCIe擴充卡、硬碟)進行通訊。MCTP(Management Component Transport Protocol)是一種位元組對齊(byte-aligned)訊息系統，運行在現有的實體層或通訊協定之上。也因此，它被稱為[傳輸層Transport Layer]，它只有定義用於管理與控制相關訊息的位元組，而不定義這些位元組如何被實體傳送。
如下圖所呈現的，灰色區塊代表底層實體層(例如PCIe)的典型標頭與尾部區段，橙色與綠色區塊則是由MCTP定義的資料字節。對底層實體層而言，MCTP封包僅僅是資料(payload)字節，並遵循該實體層採用相同的編碼與映射。
為了進一步説明這個概念，可以想象一個系統主機板上裝有一個透過PCIe 插槽連接的固態硬盤(SSD)。在MCTP的架構中，這個SSD被視為一個受控制裝置。MCTP控制訊息可以透過PCIe協定本身，在CPU與SSD之間傳輸。如下圖:
如果你曾經使用過PCIe，就會知道它是一種高效能且非常複雜的總線，因此它更適合用於執行實際的任務模式傳輸(例如以最高速度從SSD讀取大檔案)，而不是用來進行系統管理。這也是為什麼在許多實際應用中，MCTP協定通常運行在其他較簡單的實體層之上，例如SMBus或I2C。而現在隨着最新的I3C，MCTP協定也可以順利地運作在I3C實體層上！
MCTP請求與回應訊息在SMBus/I²C上的處理方式
在這種情況下，所有MCTP封包交易皆以SMBus寫入交易(write transaction) 的形式進行，用於在裝置間傳送請求或迴應訊息。因此，總線上的每個裝置(即使是控制器)都必須擁有一個地址，以作為交易的目標。如圖4所示，MCTP 封包在SMBus/I²C上的格式增加了四個位元組(byte 1到byte 4)，用以定義媒介專屬標頭(medium-specific header)：
● byte 1–3(目的從屬裝置地址、指令碼、字節數)為SMBus欄位。
● byte 4(來源從屬裝置地址)由MCTP新增，用於方便將回應訊息傳回給發出請求的裝置。
其餘字節(byte 5到byte N1)則為典型的傳輸層標頭與資料負載(如圖1所示)。值得注意的是，MCTP封包完成後會附加一個封包錯誤碼(PEC, Packet Error Code)字節，這是MCTP協定為確保傳輸可靠性所要求的。
MCTP寫入與讀取訊息在 I3C 上的處理方式
如前所述，對於MCTP在SMBus/I²C上的應用，所有交易都是以寫入傳輸(write transfer)的形式進行。然而，在I3C的情況下，封包傳輸會依通訊方向而有所不同：
● Host device to Slave device：採用主裝置發起的寫入傳輸(primary-initiated write transfer)。
● Slave device to Host device：可透過兩種模式進行：帶內中斷模式(IBI mode, In-Band Interrupt)或輪詢模式(polling mode)。
在先前的文章中，我們已展示如何在I3C上構建MCTP的寫入與讀取命令，圖 5 為方便起見也附於此。繼續閲讀可瞭解SV6E-X如何成為一個簡單易用的工具，在I3C以及SMBus/I²C上執行這類測試。
在SMBus 或 I2C 與 I3C上測試MCTP
Introspect SV6E-X Mid-Frequency Digital Test Module是Introspect的獲獎解決方案，用於測試與驗證I²C、I3C界面及其衍生協定。它自然也能輕鬆支援MCTP協定，簡單來説，SV6EX可以當作Host device發送MCTP訊息到Slave device，也可以當Salve接收並回應Host的訊息。使用時，封包欄位和錯誤檢查位元(PEC)都會自動處理，使用者不需手動計算。此外，SV6EX也可以作為協定分析儀或示波器使用，這些功能同樣適用於MCTP測試。圖6和圖7分別展示了使用協定分析儀譯碼 MCTP 傳輸的範例。
結論
透過這篇文章，説明了MCTP協定以及其如何打包在SMBus與I²C或MIPI I3C協定之上，以便從Host向Slave傳送訊息，並展示了Slave如何將回應訊息傳回Host。最後，我們介紹了Introspect SV6E-X Mid-Frequency Digital Test Module，説明其如何自然地支援 MCTP 測試，使設計、除錯與特性分析測試MCTP裝置變得更加簡單。如果你對於MCTP測試或是I3C feature開發驗證與設計上有任何的疑問，也歡迎隨時跟我們聯繫。