1

2

3 Document Identifier: DSP0233

4 Date: 2021-06-23

5 Version: 1.0.0

6 Management Component Transport Protocol 7 (MCTP) I3C Transport Binding Specification

8 Supersedes: None

9 Document Class: Normative

10 Document Status: Published

11 Document Language: en-US

MCTP I3C Transport Binding Specification DSP0233

12

13 Copyright Notice

14 Copyright © 2021 DMTF. All rights reserved.

15 DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems 16 management and interoperability. Members and non-members may reproduce DMTF specifications and 17 documents, provided that correct attribution is given. As DMTF specifications may be revised from time to 18 time, the particular version and release date should always be noted.

19 Implementation of certain elements of this standard or proposed standard may be subject to third party 20 patent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representations 21 to users of the standard as to the existence of such rights, and is not responsible to recognize, disclose, 22 or identify any or all such third party patent right, owners or claimants, nor for any incomplete or 23 inaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability to 24 any party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize, 25 disclose, or identify any such third party patent rights, or for such party’s reliance on the standard or 26 incorporation thereof in its product, protocols or testing procedures. DMTF shall have no liability to any 27 party implementing such standard, whether such implementation is foreseeable or not, nor to any patent 28 owner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard is 29 withdrawn or modified after publication, and shall be indemnified and held harmless by any party 30 implementing the standard from any and all claims of infringement by a patent owner for such 31 implementations.

32 For information about patents held by third-parties which have notified the DMTF that, in their opinion, 33 such patent may relate to or impact implementations of DMTF standards, visit 34 http://www.dmtf.org/about/policies/disclosures.php.

35 PCI-SIG, PCIe, and the PCI HOT PLUG design mark are registered trademarks or service marks of PCI- 36 SIG. I3C is a registered service mark of MIPI Alliance, Inc.

37 All other marks and brands are the property of their respective owners.

38 This document’s normative language is English. Translation into other languages is permitted.

39

2 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

40 CONTENTS

41 Foreword ...... 5 42 Introduction...... 7 43 1 Scope ...... 9 44 2 Normative references ...... 9 45 3 Terms and definitions ...... 9 46 4 Conventions ...... 13 47 4.1 Reserved and unassigned values ...... 13 48 4.2 Byte ordering ...... 13 49 5 MCTP over I3C transport ...... 13 50 5.1 MCTP use with I3C ...... 13 51 5.1.1 I3C bus physical topology ...... 13 52 5.1.2 I3C communication logical topology and MCTP packet bridging ...... 14 53 5.1.3 MCTP Bus Owner for I3C bus ...... 15 54 5.2 MCTP packet encapsulation ...... 16 55 5.2.1 MCTP packet encapsulation: Primary to Slave ...... 16 56 5.2.2 MCTP packet encapsulation: Slave to Primary ...... 18 57 5.3 Error detection and handling mechanisms ...... 23 58 5.3.1 MCTP data packets ...... 23 59 5.3.2 CCC error detection and handling ...... 24 60 5.3.3 “Stuck SDA" condition handling ...... 25 61 5.4 MCTP support and capabilities discovery...... 26 62 5.4.1 Initialization and discovery flow ...... 26 63 5.4.2 Transmission unit sizes ...... 27 64 5.5 Supported media ...... 28 65 5.6 Physical address format for MCTP control messages ...... 28 66 5.7 Get endpoint ID medium-specific information ...... 29 67 5.8 MCTP packet and control message timing requirements ...... 29 68 ANNEX A (informative) Notation ...... 32 69 ANNEX B (informative) Change log ...... 33 70

71 Figures

72 Figure 1 – Physical topology of I3C bus ...... 14 73 Figure 2 – Logical topology of MCTP over I3C communication ...... 14 74 Figure 3 – Sample I3C slave as MCTP Bus Owner & bridge ...... 16 75 Figure 4 – MCTP over I3C packet transfer format: Primary to Slave ...... 17 76 Figure 5 – MCTP over I3C packet transfer sequence: Slave to Primary ...... 19 77 Figure 6 – MCTP over I3C packet transfer format: Slave to Primary ...... 20 78 Figure 7 – Sample I3C dynamic address assignment flow and MCTP discovery ...... 26 79 80

Version 1.0.0 Published 3 MCTP I3C Transport Binding Specification DSP0233

81 Tables

82 Table 1 – MCTP packet transfer field descriptions ...... 17 83 Table 2 – IBI pending read notification field descriptions ...... 21 84 Table 3 – MCTP packet transfer field descriptions ...... 21 85 Table 4 – Recommended behaviors for robust CCCs ...... 24 86 Table 5 – Physical address format ...... 28 87 Table 6 – Medium-specific information ...... 29 88 Table 7 – Timing specifications for MCTP data packets on I3C ...... 29 89 Table 8 – Timing specifications for MCTP control messages on I3C ...... 29 90

4 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

91 Foreword

92 The Management Component Transport Protocol (MCTP) I3C Transport Binding Specification (DSP0233) 93 was prepared by the DMTF PMCI Working Group in close cooperation with the MIPI Alliance I3C Working 94 Group.

95 DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems 96 management and interoperability.

97 MIPI Alliance is a collaborative global organization serving industries that develop mobile and mobile- 98 influenced devices. The focus of the organization is to design and promote hardware and software 99 interfaces that simplify the integration of components built into a device, from the antenna and modem to 100 peripherals and the application processor.

101 This version is the first version of this document. Future changes with be detailed in the change log in 102 ANNEX B.

103 Acknowledgments

104 The DMTF acknowledges the following individuals for their contributions to this document:

105 Editors:

106 • Janusz Jurski – Intel Corporation 107 • Myron Loewen – Intel Corporation 108 • Amit K Srivastava – Intel Corporation

109 DMTF Contributors:

110 • Patrick Caporale – Lenovo 111 • Yuval Itkin – NVIDIA Corporation 112 • John Leung – Intel Corporation 113 • Eliel Louzoun – Intel Corporation 114 • Balaji Natrajan – Microchip Technology Inc. 115 • Edward Newman – Hewlett Packard Enterprise 116 • Jim Panian – Qualcomm Incorporated 117 • William Scherer III – Hewlett Packard Enterprise 118 • Hemal Shah – Broadcom Inc 119 • Bob Stevens – Dell Inc. 120 • Johan Van De Groenendaal – Intel Corporation

121 MIPI Contributors:

122 • Guruprasad Ardhanari – Intel Corporation 123 • Jerry Backer – Intel Corporation 124 • Rajesh Bhaskar – Intel Corporation 125 • Enrico D Carrieri – Intel Corporation 126 • Anamitra Chakrabarti – Synopsys, Inc. 127 • Kelly J Couch – Intel Corporation 128 • Kenneth P Foust – Intel Corporation 129 • Chris Grigg – MIPI Alliance (Team) 130 • David Harriman – Intel Corporation 131 • Prakash Iyer – Intel Corporation 132 • Paul Kimelman – NXP Semiconductors 133 • Lukasz Lanecki – Intel Corporation

Version 1.0.0 Published 5 MCTP I3C Transport Binding Specification DSP0233

134 • Richard Marian Thomaiyar – Intel Corporation 135 • Tim E Mckee – Intel Corporation 136 • Mariusz Oriol – Intel Corporation 137 • Ankit Rohatgi – MIPI Alliance (Team) 138 • Matthew Schnoor – Intel Corporation 139 • Eyuel Zewdu Teferi – STMicroelectronics 140 • George Vergis – Intel Corporation 141

142

6 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

143 Introduction

144 The Management Component Transport Protocol (MCTP) over I3C transport binding defines a transport 145 binding for facilitating communication between platform management subsystem components (e.g., 146 management controllers, managed devices) over I3C.

147 The Management Component Transport Protocol (MCTP) Base Specification describes the protocol and 148 commands used for communication within and initialization of an MCTP network. The MCTP over I3C 149 transport binding definition in this specification includes a packet format, physical address format, 150 message routing, and discovery mechanisms for MCTP over I3C communications. 151 NOTE: The terms Master and Slave used in the referenced document have been replaced in this document with the 152 terms Primary and Secondary. 153

Version 1.0.0 Published 7 MCTP I3C Transport Binding Specification DSP0233

154

8 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

155 Management Component Transport Protocol (MCTP) I3C 156 Transport Binding Specification

157 1 Scope

158 This document provides the specifications for the Management Component Transport Protocol (MCTP) 159 transport binding for I3C.

160 2 Normative references

161 The following referenced documents are indispensable for the application of this document. For dated or 162 versioned references, only the edition cited (including any corrigenda or DMTF update versions) applies. 163 For references without a date or version, the latest published edition of the referenced document 164 (including any corrigenda or DMTF update versions) applies.

165 DMTF, DSP0236, Management Component Transport Protocol (MCTP) Base Specification 1.3, 166 https://www.dmtf.org/dsp/DSP0236

167 DMTF, DSP0239, Management Component Transport Protocol (MCTP) IDs and Codes 1.8, 168 https://www.dmtf.org/dsp/DSP0239

169 Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic, Version 1.0, 170 https://www.mipi.org/specifications/i3c-sensor-specification

171 MIPI Mandatory Data Byte (MDB) Values Table, 172 https://www.mipi.org/MIPI_I3C_mandatory_data_byte_values_public

173 MIPI Device Characteristics Register (DCR) Assignments, 174 https://www.mipi.org/MIPI_I3C_device_characteristics_register

175 System Management Bus (SMBus) Specification v2.0, SBS Implementers Forum, SMBus, August 2000, 176 http://www.smbus.org/specs/smbus20.pdf

177 MIPI I3C℠ Host Controller Interface℠ v1.0 Specification, MIPI, April 2018, 178 https://www.mipi.org/specifications/i3c-hci

179 3 Terms and definitions

180 In this document, some terms have a specific meaning beyond the normal English meaning. Those terms 181 are defined in this clause.

182 The terms "shall" ("required"), "shall not", "should" ("recommended"), "should not" ("not recommended"), 183 "may", "need not" ("not required"), "can" and "cannot" in this document are to be interpreted as described 184 in ISO/IEC Directives, Part 2, Clause 7. The terms in parentheses are alternatives for the preceding term, 185 for use in exceptional cases when the preceding term cannot be used for linguistic reasons. Note that 186 ISO/IEC Directives, Part 2, Clause 7 specifies additional alternatives. Occurrences of such additional 187 alternatives shall be interpreted in their normal English meaning.

188 The terms "clause", "subclause", "paragraph", and "annex" in this document are to be interpreted as 189 described in ISO/IEC Directives, Part 2, Clause 6.

Version 1.0.0 Published 9 MCTP I3C Transport Binding Specification DSP0233

190 The terms "normative" and "informative" in this document are to be interpreted as described in ISO/IEC 191 Directives, Part 2, Clause 3. In this document, clauses, subclauses, or annexes labeled "(informative)" do 192 not contain normative content. Notes and examples are always informative elements.

193 Refer to Management Component Transport Protocol (MCTP) Base Specification for the terms and 194 definitions that are used across the MCTP specifications.

195 For the purposes of this document, the following terms and definitions apply.

196 197 Address Resolution Protocol 198 ARP 199 refers to the procedure used to dynamically determine the addresses of devices on a shared 200 communication medium

201 202 ACK 203 Acknowledge

204 205 BCR 206 Bus Characteristics Register – see Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic 207 for more information

208 209 BMC 210 Baseboard management controller

211 212 CCC 213 Common Command Code – see Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic 214 for more information

215 216 Destination Device 217 Device receiving the MCTP packet over I3C bus

218 219 EEPROM 220 Electrically Erasable Programmable Read-Only Memory

221 222 EID 223 Endpoint identifier

224 225 HCI 226 Host Controller Interface

227 228 Hot-Join 229 Joining the Bus after it is already started – see Specification for I3C BasicSM, Improved Inter Integrated 230 Circuit – Basic for more information

10 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

231 232 I3C 233 Improved Inter-Integrated Circuit – see Specification for I3C BasicSM, Improved Inter Integrated Circuit – 234 Basic for more information

235 236 IBI 237 In-Band Interrupt – see Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic for more 238 information

239

240 241 max 242 maximum

243 244 MCTP 245 Management Component Transport Protocol

246 247 MDB 248 Mandatory Data Byte

249 250 MHz 251 megahertz

252 253 min 254 minimum

255 256 ms 257 millisecond

258 259 MSB 260 most significant byte

261 262 MTU 263 Maximum Transmission Unit

264 265 NACK 266 not acknowledge

267 268 PCI 269 peripheral component interconnect

270

Version 1.0.0 Published 11 MCTP I3C Transport Binding Specification DSP0233

271 PCIe® 272 PCI Express™

273 274 PEC 275 packet error code

276 277 PMCI 278 Platform Management Component Intercommunications

279 280 Primary

281 Alternative term for the current I3C Master as defined in Specification for I3C BasicSM, 282 Improved Inter Integrated Circuit – Basic 283 SCL 284 serial clock

285 286 SDA 287 serial data

288 289 sec 290 second

291 292 Secondary 293 Alternative term for I3C Slave as defined in Specification for I3C BasicSM, Improved Inter Integrated 294 Circuit – Basic

295

296 297 SMBus 298 System Management Bus

299 300 Source Device 301 Device sending the MCTP packet over I3C bus

302 303 T-bit 304 Transition bit – see Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic for more 305 information

306 307 UDID 308 unique device identifier

12 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

309 4 Conventions

310 The conventions described in the following clauses apply to this specification.

311 4.1 Reserved and unassigned values

312 Unless otherwise specified, any reserved, unspecified, or unassigned values in enumerations or other 313 numeric ranges are reserved for future definition by the DMTF.

314 Unless otherwise specified, numeric or bit fields that are designated as reserved shall be written as 0 315 (zero) and ignored when read.

316 4.2 Byte ordering

317 Unless otherwise specified, byte ordering of multi-byte numeric fields or bit fields is "Big Endian" (that is, 318 the lower byte offset holds the most significant byte, and higher offsets hold lesser significant bytes).

319 5 MCTP over I3C transport

320 The MCTP over I3C transport binding defines how MCTP packets are delivered over a physical I3C 321 medium using I3C transfers. See Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic 322 for complete details about I3C requirements, including the electrical layer. This specification defines 323 additional requirements and supersedes the Specification for I3C BasicSM, Improved Inter Integrated 324 Circuit – Basic in any cases when there are differences.

325 This binding specification has been designed to be able to share the same bus with devices 326 communicating using other I3C protocols (e.g., MIPI Debug for I3CSM – see clause 5.4.1) and compatible 327 SMBus/I2C devices (e.g., EEPROM). Interactions with such devices or protocols are out of scope for this 328 specification.

329 5.1 MCTP use with I3C

330 5.1.1 I3C bus physical topology

331 The physical topology of the I3C bus is presented in Figure 1. There is a single device that plays the role 332 of the Primary (typically it is a Management Controller, Embedded Controller, etc.) and there may be 333 multiple Secondaries sharing the same I3C bus. Specification for I3C BasicSM, Improved Inter Integrated 334 Circuit – Basic defines the secondary Primary flow but that is not required for implementing MCTP and is 335 out of scope for this specification.

Version 1.0.0 Published 13 MCTP I3C Transport Binding Specification DSP0233

Chassis Add-in MCTP Power Management Controller Supply PCI Express PCI Express Card (I3C Slave) (non-MCTP) Card Card

MCTP MCTP MCTP Connector Controller Controller Controller (I3C Slave) Cable (I3C Slave) (I3C Slave)

Connector Connector Connector Connector Motherboard

MCTP Mgmt I3C Controller (I3C Master) Temperature EEPROM MCTP Controller Sensor (non-MCTP) (I3C Slave) (non-MCTP)

336

337 Figure 1 – Physical topology of I3C bus

338

339 5.1.2 I3C communication logical topology and MCTP packet bridging

340 The topology of the logical communication paths is shown in Figure 2. The Primary can communicate to 341 any of the Secondaries. Each Secondary can communicate with the Primary only. Any communications 342 between Secondaries are implemented by MCTP bridge functionality in the Primary, according to the 343 Management Component Transport Protocol (MCTP) Base Specification. Unlike typical MCTP bridges 344 that transfer data to another port, this data may be retransmitted to the same port. When forwarding, the 345 physical addressing and PEC gets changed by the bridge to match the requirements of the destination 346 bus.

MCTP S MCTP S Endpoint Endpoint

MCTP M Endpoint & Bridge

MCTP S MCTP S Endpoint Endpoint 347

348 Figure 2 – Logical topology of MCTP over I3C communication

14 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

349 Note that the Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic has its own concept 350 of an I3C bridge device and it requires that I3C bridges implement certain functionality and report their 351 capability using BCR[4] flag. MCTP bridges are a different concept from I3C bridges.

352 There is no relationship between the physical layer I3C addresses and the transport protocol layer MCTP 353 EIDs. I3C addresses are assigned by the I3C Primary, while MCTP EIDs are assigned by the MCTP Bus 354 Owner. These two functions are logically independent but they may be collocated.

355 5.1.3 MCTP Bus Owner for I3C bus1

356 As defined in Management Component Transport Protocol (MCTP) Base Specification, MCTP Bus Owner 357 device is responsible for MCTP endpoints discovery and managing MCTP EID assignments. EID 358 assignment requires physical addressing to be used (with EID = 0, i.e., Null Destination EID or Null 359 Source EID). On the I3C bus, direct communication can only happen with the I3C Primary either as a 360 source or a destination, as described in the previous clause.

361 There may be multiple logical MCTP buses overlaid on a single I3C physical bus:

362 • Preferably, the I3C Primary is the MCTP Bus Owner. It can discover all the I3C Secondaries and 363 fulfil the MCTP Bus Owner role for the whole I3C bus (see clause 5.4.1 for the flow details). 364 • Additionally, an I3C Secondary can be an MCTP Bus Owner but only for the connection between 365 it and the I3C Primary (see clause 5.4.1 for the flow details as well). Other I3C Secondary devices 366 on the I3C bus are not directly reachable by the I3C Secondary. I3C Secondary acting as an 367 MCTP Bus Owner enables it to act as an MCTP bridge from another MCTP bus. An I3C 368 Secondary that acts as an MCTP Bus Owner cannot be added to an I3C bus using the I3C hot- 369 join mechanism.

370 For example, as shown in Figure 3, two logical buses are created and EIDs are assigned as follows:

371 • Logical MCTP Bus 1, Bridge 1 (I3C Secondary) is the MCTP Bus Owner – Bridge 1 assigns the 372 EID and EID pool to the I3C Primary because I3C Primary is an endpoint on the Logical MCTP 373 Bus 1. 374 • Logical MCTP Bus 2, Bridge 2 (I3C Primary) is the MCTP Bus Owner for Logical MCTP Bus 2 – 375 Bridge 2 assigns EIDs to all the remaining I3C Secondaries.

376 This concept can be extended and each device on an I3C bus could be a MCTP Bridge to additional 377 MCTP networks.

1 The term “bus” is used in a different meaning in Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic and in Management Component Transport Protocol (MCTP) Base Specification context. This clause describes a scenario when multiple MCTP buses are overlaid on a single I3C bus.

Version 1.0.0 Published 15 MCTP I3C Transport Binding Specification DSP0233

Topmost MCTP Bus Owner

MCTP Bus S Owner & Bridge 1 MCTP S Endpoint 2 MCTP M Bus Owner & Bridge 2

MCTP S MCTP S Endpoint 1 Endpoint 3 378

379 Figure 3 – Sample I3C Secondary as MCTP Bus Owner & bridge

380

381 5.2 MCTP packet encapsulation

382 MCTP packet transfers over I3C slightly differ depending on the communication direction:

383 • Primary to Secondary communication follows encapsulation defined in clause 5.2.1

384 • Secondary to Primary communication follows encapsulation defined in clause 5.2.2

385 Subclauses below capture the MCTP packet encapsulation details. There is no requirement for the multi- 386 packet MCTP message to be contiguous on the bus.

387 5.2.1 MCTP packet encapsulation: Primary to Secondary

388 5.2.1.1 Overview

389 Transmission of MCTP packets from the Primary to the Secondary happens using Primary-initiated 390 private write transfer as defined in Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic. 391 The transfer shall be directed to the Secondary I3C address used for MCTP protocol communication. For 392 the purpose of this specification, a Secondary shall only support the MCTP protocol at its unique 393 Secondary address and an I3C address shall be dynamically assigned for that purpose. See clause 5.4.1 394 for discussion about protocol discovery when other protocols may be in use on the I3C bus.

395 The MCTP message header and MCTP message data fields map to I3C payload as indicated in Figure 4. 396 After the MCTP message data, there is a PEC byte added – its role is discussed in clause 5.3.1. Please 397 note that the length of the write transfer is dictated by the Primary using Repeated Start/Stop condition. 398 Primary is expected to obey the discovered maximum write length (see clause 5.4.2 for more 399 information).

16 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

400 Note that the Secondary does not need I3C address of the Primary because all MCTP packets from a 401 given Secondary will always be directed to the Primary – the Primary has no explicit address as per 402 Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic. MCTP Destination EID should be 403 used to route the MCTP packet to another Secondary if necessary.

+0 +1 +2 +N I3C Destination S / Sr ACK Write Data 1 T Write Data 2 Write Data N T Sr/P Address (RnW=0)

+1 +2 +3 +4

7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 S E Pkt MCTP Hdr Destination Source T Msg O O Seq Reserved Version Endpoint ID Endpoint ID O Tag M M # Message Message I Msg Type Message Integrity C Header Data Check

PEC 404

405 Figure 4 – MCTP over I3C packet transfer format: Primary to Secondary

406 Please note that the MCTP packet transfer shown may be preceded by the optional I3C Broadcast 407 Address (7’h7E), as defined in the I3C specification. In this transaction, the T-bit is the parity of each byte.

408 As per the Management Component Transport Protocol (MCTP) Base Specification, IC and Message 409 Type byte is only present in the first packet of a fragmented MCTP message.

410 Table 1 – MCTP packet transfer field descriptions

Byte I3C Field(s) Description 0 Destination Address [7:1] I3C Destination Address: The address of the Secondary on the local I3C bus RnW [0] I3C RnW# bit: Shall be set to 0b as all MCTP messages using I3C write transfers. 1 Write Data 1 [7:4] MCTP reserved: This nibble is reserved for definition by the Management Component Transport Protocol (MCTP) Base Specification. [3:0] MCTP header version: Set to 0001b for MCTP v1 devices that are conformant to the Management Component Transport Protocol (MCTP) Base Specification and this version of the MCTP transport binding. All other values = Reserved.

Version 1.0.0 Published 17 MCTP I3C Transport Binding Specification DSP0233

Byte I3C Field(s) Description 2 Write Data 2 Destination endpoint ID (*) as defined in Management Component Transport Protocol (MCTP) Base Specification, including special endpoint IDs 3 Write Data 3 Source endpoint ID (*) as defined in Management Component Transport Protocol (MCTP) Base Specification, including special endpoint IDs 4 Write Data 4 [7] SOM: Start Of Message flag (*) [6] EOM: End Of Message flag (*) [5:4] MCTP Packet sequence number (*) [3] Tag Owner (TO) bit (*) [2:0] Message tag (*) 5 Write Data 5 [7] IC: Integrity Check bit (*) [6:0] Message type (*) 6:N-1 Write Data 6:N-1 MCTP message header and data (*)

N PEC Packet error code (PEC): All MCTP I3C transfers shall include a PEC byte. The PEC byte shall be transmitted by the source and checked by the destination. Please see clause 5.3.1 for more information.

(*) Indicates a field that is defined by the Management Component Transport Protocol (MCTP) Base Specification.

411 5.2.1.2 Secondary address ACKs/NACKs

412 The Primary can start another write transfer after the Repeated Start condition on the bus, meaning that 413 multiple MCTP packets can follow one after the other in sequence. In case the Secondary buffer cannot 414 accommodate the maximum packet length (as negotiated according to clause 5.4.2), it shall NACK its 415 address to indicate the potential overflow and a need for retry later. The time to retry is dependent on the 416 implementation – see clause 5.8 for more information.

417 NACK of a Secondary address may indicate that the device buffers are full or the physical absence of the 418 device. The Primary may test for the presence of a device after a NACK with the GETSTATUS CCC. The 419 Secondary shall always respond to GETSTATUS CCC, even if its MCTP data buffer is full. The Primary 420 shall retry GETSTATUS CCC as per Specification for I3C BasicSM, Improved Inter Integrated Circuit – 421 Basic, clause 5.1.9.2.3 Retry Model for Direct GET CCC Commands, before it considers the device as 422 absent.

423 5.2.2 MCTP packet encapsulation: Secondary to Primary

424 Transmission of MCTP packets from Secondary to Primary can happen in two modes:

425 • In-Band Interrupt mode (IBI mode) or 426 • polling mode (described in clause 5.2.2.4).

427 The Secondary is required to support both modes of operation and the Primary can enable or disable IBIs 428 as defined in Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic.

18 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

429 5.2.2.1 Overview – IBI mode

430 Transmission of MCTP packets from Secondary to Primary according to the IBI mode shall happen using 431 the following general sequence:

432 1. When the Secondary has a MCTP packet ready for transmission to the Primary, it shall initiate an 433 I3C IBI with MDB = 0xAE (as assigned in MIPI Mandatory Data Byte (MDB) Values Table 434 registry) to inform the Primary about the data ready.

435 2. The Primary shall read the MCTP packet (or multiple packets) from the Secondary using I3C 436 Private Read transfer.

437 This sequence is illustrated in Figure 5: Master Slave

Slave prepares MCTP packet in the transmit buffer and initiates IBI

Slave waits for Master to read MCTP packet data IBI triggers Master to initiate I3C read(s) from Slave device s buffer to fetch MCTP packet

438

439 Figure 5 – MCTP over I3C packet transfer sequence: Secondary to Primary

Version 1.0.0 Published 19 MCTP I3C Transport Binding Specification DSP0233

440 The transaction field explanations are illustrated in Figure 6 and in Table 2 (for pending read notification) 441 and Table 3 (for the MCTP packet transfer):

442

443 Figure 6 – MCTP over I3C packet transfer format: Secondary to Primary

444 As defined in the Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic, the read transfer 445 may start with:

446 (a) Repeated Start condition and the I3C Source Secondary address immediately after the IBI or 447 other traffic – for example, using HCI auto-command as defined in MIPI I3C℠ Host Controller 448 Interface℠ Specification 449 (b) Start condition and the Secondary address 450 (c) Start condition with I3C Broadcast Address (7’h7E), then Repeated Start with the Secondary 451 address

452 In these transactions, the T-bit is zero to indicate the End-of-Data – see Specification for I3C BasicSM, 453 Improved Inter Integrated Circuit – Basic, clause 5.1.2.3.4 Ninth Bit of SDR Slave Returned (Read) Data 454 as End-of-Data.

455 As per the Management Component Transport Protocol (MCTP) Base Specification, IC and Message 456 Type byte is only present in the first packet of a fragmented MCTP message.

20 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

457 Table 2 – IBI pending read notification field descriptions

Byte I3C Field(s) Description 0 Source Address [7:1] I3C Source Address: The address of the Secondary device RnW [0]: I3C RnW# bit: Shall be set to 1b for all IBIs 1 Mandatory Data [7:0] 0xAE value – MCTP Pending Read ID notiofication as defined in Byte (MDB) MIPI Mandatory Data Byte (MDB) Values Table registry

458

459 Table 3 – MCTP packet transfer field descriptions

Byte I3C Field(s) Description 0 Source Address [7:1] I3C Source Address: The address of the Secondary device RnW [0]: I3C RnW# bit: Shall be set to 1b for all Read transfers. 1 Read Data 1 [7:4] MCTP reserved: This nibble is reserved for definition by the Management Component Transport Protocol (MCTP) Base Specification. [3:0] MCTP header version: Set to 0001b for MCTP v1 devices that are conformant to the Management Component Transport Protocol (MCTP) Base Specification and this version of the MCTP transport binding. All other values = Reserved. 2 Read Data 2 Destination endpoint ID (*) as defined in Management Component Transport Protocol (MCTP) Base Specification, including special endpoint IDs 3 Read Data 3 Source endpoint ID (*) as defined in Management Component Transport Protocol (MCTP) Base Specification, including special endpoint IDs 4 Read Data 4 [7] SOM: Start Of Message flag (*) [6] EOM: End Of Message flag (*) [5:4] MCTP Packet sequence number (*) [3] Tag Owner (TO) bit (*) [2:0] Message tag (*) 5 Read Data 5 [7] IC: Integrity Check bit (*) [6:0] Message type (*) 6:N-1 Read Data 6:N-1 MCTP message header and data (*) N PEC Packet error code (PEC): All MCTP I3C transfers shall include a PEC byte. The PEC byte shall be transmitted by the source and checked by the destination. Please see clause 5.3.1 for more information.

(*) Indicates a field that is defined by the Management Component Transport Protocol (MCTP) Base Specification.

460

Version 1.0.0 Published 21 MCTP I3C Transport Binding Specification DSP0233

461 5.2.2.2 Detailed flow

462 When a Secondary has an MCTP packet available to transfer, it initiates the flow by sending an IBI with a 463 Mandatory Data Byte (MDB) value = 0xAE. This is to inform the Primary that an MCTP packet is available 464 for reading from the Secondary. The Primary should acknowledge the IBI request and read the MDB data 465 from the Secondary. After accepting the request, the Primary may read the packet immediately with a 466 Repeated Start after the IBI or it may do this at a later time. The Primary may queue up several IBI 467 notifications from multiple Secondaries and process them in any order. Delaying reads allows 468 prioritization as well as management of shared buffers.

469 When sending the IBI notification, the Secondary needs to ensure that the MDB has been read by the 470 Primary and ensure the data is available for the next private read request from the Primary. If the Primary 471 NACKs the IBI, then the IBI was not accepted and the Secondary shall retry the IBI at the next 472 opportunity as per Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic, section 5.1.6.2, 473 Slave Interrupt Request and conformant to section 5.8. The Secondary may interpret consecutive NACKs 474 of an IBI as an error and take actions dependent on implementation.

475 Once the Secondary has sent all the bytes of the MCTP packet and the PEC byte, the Secondary shall 476 indicate the end of data transfer, and the Primary completes the I3C transaction. The next MCTP packet 477 transfer shall happen in a separate transfer. The error cases for this rule are described in clause 5.2.2.7.

478 5.2.2.3 ACKed IBI retransmissions

479 Each Secondary shall also implement a timeout mechanism in order to retransmit the IBI. The timer shall 480 be started when the Primary acknowledges the IBI with MDB and the Secondary is allowed to retransmit 481 the IBI if the read has not happened after this timeout expiration. The number of retransmits and the 482 timeout value are implementation dependent – depends on the Secondary functionality and 483 characteristics of MCTP traffic (urgency of retransmission) and shall conform to clause 5.8 requirements. 484 The Secondary shall also wait for at least one Tidle condition on the bus between retransmits.

485 5.2.2.4 Polling mode

486 The Primary can operate in polling mode when IBIs are disabled. In this case, the Primary can do a 487 GETSTATUS CCC to find if IBIs are pending or it may simply attempt read transfers from the Secondary 488 and see if it responds with data. The Primary should ensure a packet read happens within PT timeout, as 489 per clause 5.8.

490 5.2.2.5 Sequences of multiple MCTP packets and reads without IBIs

491 If the Secondary has multiple MCTP packets to send to the Primary, it may signal multiple IBIs, one for 492 each packet. This may happen even if waiting for the Primary to initiate a private read request on a prior 493 MCTP packet. A Secondary may only signal multiple ready packets if it is able to service sequential 494 Primary reads separated by a Repeated Start. Slaves that are unable to respond quickly enough to a 495 sequence of reads separated by Repeated Start conditions shall delay IBI notifications of additional 496 packets until after the prior packet is read.

497 The Primary may also do multiple MCTP packets reads in a sequence even without having received 498 multiple IBIs, as in the following examples:

499 • If the Primary receives a multi-packet MCTP message, it may attempt to read subsequent MCTP 500 packets until EOM flag is set in the MCTP header,

501 • The Primary knows that the Secondary transmits MCTP packets on strictly periodical basis,

502 • The Primary expects more MCTP packets, so it decides to continue reading until a NACK is 503 received (see clause 5.2.2.6 for more information).

22 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

504 In the above scenarios, the Secondary shall not send IBIs related to packets that have been read by the 505 Primary.

506 If IBIs are disabled, the Secondary shall still support Primary-initiated reads and provide the next 507 available MCTP packets.

508 5.2.2.6 NACKs

509 If the Primary attempts a read when the Secondary has no MCTP packets ready to send, then the 510 Secondary shall NACK the address byte.

511 The Primary shall follow the flow discussed in clause 5.2.1.2 to differentiate between a Secondary device 512 no longer present and a Secondary device NACKing the transfers.

513 5.2.2.7 Early terminated or prolonged reads

514 The Secondary expects the whole MCTP packet to be read by the Primary. It may happen, however, that 515 the Primary terminates the read transfer too early or too late:

516 • The Primary stops before the Secondary transmits the whole MCTP packet, including the PEC 517 byte, due to unexpected packet content, packet length limit mismatch, or bus errors.

518 • The Primary continues to drive the clock even after the Secondary indicated the end of 519 transaction due to bit error on T-bit or clock synchronization error.

520 If this happens, the Primary should interpret the last byte of the received data as PEC to detect packet 521 data corruption and discard the packet. The Secondary shall infer that the Primary received corrupted 522 MCTP packet and retransmit it again from the beginning on the next private read. If IBIs are enabled, the 523 Secondary shall use an IBI to notify the Primary that it has a packet waiting just as if it had a new packet 524 for transmission.

525 5.2.2.8 Future performance enhancements

526 IBI speeds are limited to I3C SDR mode only, so the amount of data transferred in the IBI was minimized 527 and instead transferred on a subsequent private read. This enables future migration of reads to I3C HDR 528 mode for more efficient transfer of potentially larger MCTP packets.

529 5.3 Error detection and handling mechanisms

530 5.3.1 MCTP data packets

531 MCTP relies on the underlying transport to provide packet-level error detection. For I3C, the PEC byte is 532 used to detect transmission errors as described in clause 5.2. The polynomial for CRC-8 calculation is as 533 follows – same as SMBus PEC – and the initial value and a final XOR values are zeros:

534 C(x)= x8+x2+x1+1

535 The PEC is calculated independently for each MCTP packet. The PEC calculation restarts with each Start 536 or Repeated Start condition and is inserted after each MCTP packet prior to its termination with Stop or 537 Repeated Start condition.

538 The receiver of the MCTP packet shall verify if the PEC byte is correct for the packet content. If it detects 539 an error, it should discard the received packet.

540 When the sender detects the transmission error, it is recommended to retransmit the corrupted packet. 541 These scenarios are:

Version 1.0.0 Published 23 MCTP I3C Transport Binding Specification DSP0233

542 • In case of Secondary-to-Primary transfer, if the transfer is terminated too early or too late, the 543 Secondary can retransmit the packet – see clause 5.2.2.7 for more information, 544 • If the Secondary detects error type S6 or the Primary detects error type M1, then it terminates 545 the data transfer early, as defined in Specification for I3C BasicSM, Improved Inter Integrated 546 Circuit – Basic. In this case, the MCTP packet can be retransmitted.

547 In the above case, thanks to the last byte interpreted as PEC by the receiver, the error is expected to be 548 detected and the corrupted packet data discarded.

549 5.3.2 CCC error detection and handling

550 The following recommendations should be followed in order to lower the probability of silent errors during 551 I3C CCCs:

552 • The dynamic addresses should be assigned for maximum Hamming distance between any two 553 addresses without using reserved addresses listed in Specification for I3C BasicSM, Improved 554 Inter Integrated Circuit – Basic – this is to lower the probability of an incorrect device receiving a 555 CCC, 556 • CCCs should be individually terminated with a Stop condition – this is to prevent getting stuck in 557 Dynamic Address Assignment mode, 558 • Table 4 recommends the best workarounds to make mandatory CCCs more reliable.

559 Enhancements for optional CCCs are implementation dependent.

560 Table 4 – Recommended behaviors for robust CCCs

CCC Error Description Recommended Behavior GETBCR Incorrect value read (due Keep issuing CCC until 2 consecutive read values match. to bit errors in the data Discard any reads returning invalid values. GETDCR field) or value from wrong For GETSTATUS, if the difference between the first and second GETMRL device (due to bit errors in the address field) reading is only the auto cleared Protocol Error flag they should GETMWL be considered as a match with the Protocol Error flag set. GETPID GETSTATUS ENEC Incorrect enable/disable An unexpected IBI received from a device indicates a redundant event byte value or DISEC IBI command is required. DISEC wrong address (includes S1, S2 error types If Primary times out when waiting for an IBI from a Secondary, defined in Specification then it is possible that the Secondary interrrupts are for I3C BasicSM, unintentionally disabled and the Primary should use Improved Inter Integrated GETSTATUS to see if an interrupt is pending and enable IBIs Circuit – Basic) again. ENTDAA Incorrect CCC received Assign addresses to all participating devices that do not yet have (S1 error defined in a dynamic address then repeat CCC until two consectutive Specification for I3C ENTDAAs do not detect additional devices. Confirm address BasicSM, Improved Inter assignments with ACK from directed traffic to that address. Integrated Circuit – Basic or undetected by parity check) or wrong address (due to bit errors in the address field)

24 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

CCC Error Description Recommended Behavior SETNEWDA If a new address is set Primary shall issue a GETPID CCC before and after incorrectly, wrong device SETNEWDA to verify if the same device responds at the new changes address, two address. devices may end up with same address (S2 error If there is an error (device does not respond or a different PID is type defined in detected), recovery would be via reasssigning all dynamic Specification for I3C addresses on the bus with RSTDAA. BasicSM, Improved Inter Integrated Circuit – Basic) ENTAS0 CCC not recognized by AS-type CCCs are just hints so errors can be ignored. target (S1 error defined in Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic or undetected by parity check) or wrong address (due to bit errors in the address field) RSTDAA CCC not recognized by Issue the CCC twice. target (S1 error defined in Specification for I3C BasicSM, Improved Inter Integrated Circuit – Basic or undetected by parity check) or wrong address (due to bit errors in the address field) SETMWL Incorrect value (S2 error Read back to confirm the value twice with the corresponding defined in Specification GET CCC. If the GET values differ, then keep reading until 2 SETMRL for I3C BasicSM, GET values match. If the matched values differ from the written Improved Inter Integrated value, then set it again as per clause 5.4.2. Circuit – Basic or undetected by parity check) or wrong address (due to bit errors in the address field)

561

562 5.3.3 “Stuck SDA" condition handling

563 A possible error condition exists where a Secondary that is driving the data line (SDA) of the bus could 564 continue driving the data line even when Primary expects it to be released. This can happen, for example, 565 during read transfer due to a missed clock cycle, during ACK, etc.

566 In order to recover, the Primary shall attempt the following sequence in SDR mode with an early exit as 567 soon as SDA goes high, followed by a Stop condition: 568 1. The Primary shall drive 8 clocks. The Secondary is required to drive SDA High for the 9th T-Bit. 569 The Primary shall watch for SDA going High, and stop the read by driving SDA Low when the 570 clock line (SCL) is High. 571 2. The Primary shall hold SCL level (High or Low) for 150 µs. The Secondary shall implement a 572 detector that determines if the SCL clock has not changed for 100 µs or more and switch SDA to 573 High-Z and wait for Repeated Start or Stop. 574 3. The Primary should drive SCL low for at least 35ms.

Version 1.0.0 Published 25 MCTP I3C Transport Binding Specification DSP0233

575 The last recovery step attempts to recover devices that implement SMBus timeout ttimeout as defined in 576 System Management Bus (SMBus) Specification in Table 1. SMBus AC specifications, Note 2. Such 577 devices are expected to release the SDA line after 25ms and be ready to receive a new Start condition 578 after at most 35ms.

579 5.4 MCTP support and capabilities discovery

580 Primary shall be a MCTP-aware device (typically a management controller in the system) and a MCTP 581 bridge. Primary can be connected to various Slaves that can support different protocols. For this reason, 582 a discovery method is defined in this clause to allow the Primary to find out which devices talk MCTP and 583 what characteristics they support.

584 5.4.1 Initialization and discovery flow

585 MCTP devices are identified by their Device Characteristic Registers (DCR) value of 0xCC as uniquely 586 reserved by MIPI Device Characteristics Register (DCR) Assignments. MCTP devices on an I3C bus shall 587 support Dynamic Address Assignment and removable devices shall issue Hot-Join IBIs on power up. 588 Device interrupts shall be enabled by default after the device is powered on or reset.

589 The Primary discovers which devices on the bus are capable of supporting MCTP by reading their DCR. 590 DCR can be obtained while assigning them addresses as shown in Figure 7, for example. This simplified 591 sample flow only shows setup of a single new device and does not include discovery of support for MCTP 592 packets larger than 64 bytes or alternative methods to read the DCR or assign addresses.

Current Master Target device

Upon power up, hot-plug devices periodically send a Hot Join request

Upon bus startup, receiving Hot Join, after RSTDAA, or periodically, master issues Dynamic Address Allocation ENTDAA, retry until no new devices All devices without address drive their unique 48 bit Provisional ID, BCR, and Drive 64 SCL clock cycles, records device, DCR; wait for next read if arbitration lost if DCR=0xCC then assigns it a unique address for MCTP Only device that won arbitration checks if Master loops until no more devices found odd parity, then ACKs new address and waits for STOP

Send Get MCTP Version request to confirm address assignment, device IBIs are enabled, and common MCTP version Prepare Get MCTP Version response into transmit buffer and then issue IBI Waits for Master to read Get MCTP IBI triggers Master to initiate I3C read Version response packet data from Slave device s buffer to fetch MCTP packet 593

594 Figure 7 – Sample I3C dynamic address assignment flow and MCTP discovery

26 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

595 It is assumed that the I3C Secondary will only support the MCTP protocol and a unique I3C address will 596 be dynamically assigned for that purpose. In this case, private reads and writes from this I3C address 597 only transfer MCTP packets. After an MCTP-capable I3C Primary discovers that a Secondary supports 598 MCTP, it shall send an MCTP command to the Secondary, for example, Get MCTP Version. This MCTP 599 command will inform the Secondary that the Primary supports MCTP.

600 The Discovery Notify MCTP message is used during the EID assignment process (see clause 5.1.3 for 601 more information about different logical topologies on I3C bus):

602 • If the I3C Secondary is waiting for the EID to be assigned by the I3C Primary, it shall send the 603 Discovery Notify message to the I3C Primary to trigger the EID assignment process; 604 • If the I3C Primary anticipates its EID could be assigned by a particular Secondary, it shall send 605 the Discovery Notify message directly to the Secondary to trigger the EID assignment process; 606 • If the I3C Primary does not have the predetermined knowledge about which Secondary assigns 607 the EID, the I3C Primary is allowed to send the Discovery Notify message to multiple Slaves.

608 Note that Prepare for Endpoint Discovery or Endpoint Discovery MCTP control commands are not used to 609 discover MCTP endpoints. I3C devices use the dynamic address assignment process and hot-join 610 mechanisms to discover if other I3C devices are present on or joining the I3C bus (a Secondary device 611 can only discover the presence of the Primary device, not the rest of the I3C bus, as explained in 612 clauses 5.1.2 and 5.1.3).

613 5.4.2 Transmission unit sizes

614 I3C MCTP devices shall support the minimum of 64 byte MCTP payload as the baseline (see section 8.3 615 in Management Component Transport Protocol (MCTP) Base Specification). This results in the minimum 616 I3C transfer size limit that every MCTP over I3C implementation shall support when receiving data: 69 617 bytes (i.e., 64 bytes of MCTP payload + 4 bytes of MCTP header + 1 byte of PEC). The value of 69 is the 618 default baseline transfer length for reads and writes of MCTP over I3C and cannot be negotiated smaller.

619 Secondary or Primary implementations may support longer transfers than the above default but they shall 620 discover and negotiate their use. Transfer sizes accepted by a particular MCTP Endpoint are discovered 621 as defined in Section 8.3.1 in Management Component Transport Protocol (MCTP) Base Specification, 622 i.e., via a message type specific mechanism. Transfer sizes of a path are discovered according to section 623 9.5 in Management Component Transport Protocol (MCTP) Base Specification, i.e., using Query Hop 624 MCTP commands sent to each bridge on the path.

625 In order to respond to Query Hop command, I3C devices that implement the MCTP bridging functionality 626 and transmission units larger than the baseline minimum shall use SETMWL/GETMWL and/or 627 SETMRL/GETMRL I3C CCCs to establish the maximum transfer length from Primary to Secondary or 628 from Secondary to Primary, respectively. Each direction may support a different length limit. If these pairs 629 of CCCs are not used or not supported, it means that the baseline minimum is used for a specific 630 direction of communication.

631 For the Primary-to-Secondary direction (transfers defined in clause 5.2.1), packet size limit bigger than 632 the baseline minimum may be optionally established according to the following flow:

633 (1) The Primary sends SETMWL CCC to the Secondary with the length equal to the maximum length 634 the Primary would like to send. If the Secondary is capable to support the new length, it will 635 accept it or otherwise it will change its maximum write length to the largest value it can support. 636 (2) The Primary sends GETMWL CCC to the Secondary (clause 5.3.2 rules shall be followed to 637 verify the correctness of the transfer).The Secondary responds with its current maximum write 638 length.

639 For the Secondary-to-Primary direction (transfers defined in in clause 5.2.2), packet size limit bigger than 640 the baseline minimum may be optionally established according to the following flow:

Version 1.0.0 Published 27 MCTP I3C Transport Binding Specification DSP0233

641 (1) The Primary sends SETMRL CCC to the Secondary with the length equal to the maximum length 642 the Primary would like to receive. If the Secondary is capable to support the new length, it will 643 accept it or otherwise it will change its maximum read length to the largest value it can support. 644 (2) The Primary sends GETMRL CCC to the Secondary (clause 5.3.2 rules shall be followed to verify 645 the correctness of the transfer). The Secondary responds with its current maximum read length.

646 As defined in clause 5.3.2, the above sequences may be repeated to detect and correct any transmission 647 errors.

648 The size values in these CCCs shall include the PEC defined in clause 5.3.1 as well as the MCTP header 649 fields. They do not include the I3C Secondary address fields2. Please note that SETMRL/GETMRL CCCs 650 also need to report the IBI payload size (because a Secondary that supports MCTP shall support IBIs).

651 If these CCCs are implemented, they indicate the upper bound accepted by the I3C devices. MCTP 652 maximum transmission unit cannot exceed these limits. Not all MCTP packets are of maximum length. 653 Some MCTP packets may be shorter than the above limits (either baseline or negotiated length). I3C 654 transfers will indicate the actual size of a particular packet (for reads, the T-bit is used by the Secondary 655 to indicate end of data; for writes the Primary ends the transfer with a Stop or Repeated Start). No 656 padding is needed in such a case.

657 5.5 Supported media

658 The transport binding defined in this specification has been designed to work with I3C buses. The I3C 659 media type identifier for this binding spec is defined in Management Component Transport Protocol 660 (MCTP) IDs and Codes, section 7 MCTP physical medium identifiers.

661 5.6 Physical address format for MCTP control messages

662 The address format shown in Table 5 shall be used for MCTP control commands that require a physical 663 address parameter to be returned for a bus that uses this transport binding with one of the supported 664 media types listed in 5.5. This includes commands such as the Resolve Endpoint ID, Routing Information 665 Update, and Get Routing Table Entries commands.

666 Table 5 – Physical address format

Format Size Layout and Description [7:1] I3C address bits 1 byte [0] 0b

667 A valid I3C address shall be used to refer to a Secondary. Since the Primary does not really have any 668 address, a special value of zero (7’h00) is used to indicate the Primary when it is necessary.

2 I3C specification does not clearly define if the I3C address field is included but this is the interpretation agreed at MIPI when working on this specification.

28 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

669 5.7 Get endpoint ID medium-specific information

670 The medium-specific information as shown in Table 6 shall be used for the medium-specific Information 671 field returned in the response to the Get Endpoint ID MCTP control message.

672 Table 6 – Medium-specific information

Description [7:0] reserved

673 5.8 MCTP packet and control message timing requirements

674 In I3C, all traffic passes through the Primary and it is responsible for all bus timing and fairness. The 675 Primary should attempt to ensure all device traffic makes progress, but in some cases the Primary may 676 disable interrupts or postpone some traffic to focus on higher priorities.

677 Slaves should retry packet transmission (i.e., repeat IBI notifications) until the Primary pauses retries with 678 disabled interrupts or reads the packet. In some implementations a queued packet cannot be modified or 679 retracted. If the PT expires, the endpoint may silently discard the packet.

680 When a Secondary does not accept MCTP packets from a Primary, the Primary may confirm the 681 presence of the Secondary with GETSTATUS CCC, as described in clause 5.2.1.2. If the Secondary is 682 present, the Primary may keep retrying indefinitely or stop after PT elapses.

683 Table 7 – Timing specifications for MCTP data packets on I3C

Timing Specification Symbol Value Description Endpoint packet level timeout PT 100ms The minimum time an endpoint shall attempt resending an MCTP packet in the following scenarios: • the Secondary shall retry an IBI, when it is NACKed by the Primary, or ACKed without a read, or if interrupts are disabled (IBIs that lose arbitration are not counted as an attempt), • the Primary shall retry writing a packet to a Secondary. If interrupts are enabled, there should be at least 8 retry attempts before timing out.

684 Table 8 – Timing specifications for MCTP control messages on I3C

Timing Specification Symbol Min Max Description

Endpoint ID reclaim TRECLAIM 5 sec - Minimum time that a bus owner shall wait before reclaiming the EID for a non-responsive hot-plug endpoint (i.e., not ACKing repeated GETSTATUS CCCs). 2 Number of request retries MN1 none Total of three tries, minimum: the original try plus two retries. The maximum number of retries for a given request is limited by the requirment that all retries shall occur within MT4, max of the initial request.

Version 1.0.0 Published 29 MCTP I3C Transport Binding Specification DSP0233

Timing Specification Symbol Min Max Description

Request-to-response time MT1 – 100 ms This interval is measured at the responder from the end of the reception of the MCTP Control Protocol request to the beginning of the transmission of the response (that is, beginning of IBI for Secondary initiated transfer or beginning of the write transfer for the Primary initiated transfer). This requirement is tested under the condition where the responder can successfully transmit the response on the first try.

Time-out waiting for a response MT2 MT1 max[1] MT4, min[1] This interval at the requester sets the + 2 * MT3 minimum amount of time that a max requester should wait before retrying a MCTP control request. This interval is measured at the requester from the end of the successful transmission of the MCTP control request to the beginning of the reception of the corresponding MCTP control response. NOTE: This specification does not preclude an implementation from adjusting the minimum time-out waiting for a response to a smaller number than MT2 based on the measured response times from responders. The mechanism for doing so is outside the scope of this specification.

Transmission Delay MT3 - 100 ms Time to take into account transmission delay of an MCTP Control Protocol message. Measured as the time between the end of the transmission of an MCTP Control Protocol message at the transmitter to the beginning of the reception of the MCTP Control Protocol message at the receiver.

Inter-Packet delay for Multi- MT3a - 100 ms Allowed time measured from the end of Packet messages the transmission of an MCTP packet with EOM=0 to the beginning of the following MCTP packet of the same Message (see Message assembly in Management Component Transport Protocol (MCTP) Base Specification), measured at the transmitter

Instance ID expiration interval MT4 5 sec [2] 6 sec Interval after which the instance ID for a given response will expire and become reusable if a response has not been received for the request. This is also the maximum time that a responder tracks an instance ID for a given request from a given requester.

30 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

Timing Specification Symbol Min Max Description

NOTE 1: Unless otherwise specified, this timing applies to the mandatory and optional MCTP commands.

NOTE 2: If a requester is reset, it may produce the same sequence number for a request as one that was previously issued. To guard against this, it is recommended that sequence number expiration be implemented. Any request from a given requester that is received more than MT4 seconds after a previous, matching request should be treated as a new request, not a retry.

Version 1.0.0 Published 31 MCTP I3C Transport Binding Specification DSP0233

685 ANNEX A 686 (informative) 687 688 689 Notation

690 Notations

691 Examples of notations used in this document are as follows: 692 • 2:N In field descriptions, this will typically be used to represent a range of byte offsets 693 starting from byte two and continuing to and including byte N. The lowest offset is on 694 the left, the highest is on the right. 695 • (6) Parentheses around a single number can be used in message field descriptions to 696 indicate a byte field that may be present or absent. 697 • (3:6) Parentheses around a field consisting of a range of bytes indicates the entire range 698 may be present or absent. The lowest offset is on the left, the highest is on the right. 699 • PCIe Underlined, blue text is typically used to indicate a reference to a document or 700 specification called out in 2, "Normative References" or to items hyperlinked within the 701 document. 702 • [4] Square brackets around a number are typically used to indicate a bit offset. Bit offsets 703 are given as zero-based values (that is, the least significant bit offset = 0). 704 • [7:5] A range of bit offsets. The most significant bit is on the left, the least significant bit is 705 on the right. 706 • 1b The lower case "b" following a number consisting of 0s and 1s is used to indicate the 707 number is being given in binary format. 708 • 0x12A A leading "0x" is used to indicate a number given in hexadecimal format.

709

32 Published Version 1.0.0 DSP0233 MCTP I3C Transport Binding Specification

710 ANNEX B 711 (informative) 712 713 714 Change log

Version Date Description 1.0.0 2021-06-23 715

Version 1.0.0 Published 33