|
Post by MCTP Enthusiast on Feb 10, 2023 11:34:08 GMT
Hi,
I'm using the SMBus/i2c binding specification over mctp. I believe there would not be a transfer like a block transfer in i2c if that were the preferred binding. Lines from 6.11.1 Slave addresses are shown below.
6.11.1 Slave addresses
Each device on SMBus/I 399 2C shall have a slave address to be the target of transactions by bus masters.
The MCTP transport protocol solely utilizes Master Write transactions to transfer MCTP packets between
MCTP endpoints. For endpoint "A" to send an MCTP packet to endpoint "B", endpoint A shall master the
bus and issue a Block-Write transaction to the slave address of endpoint B. Similarly, for endpoint B to
send an MCTP packet to endpoint A, it shall master the bus and issue a Block-Write transaction to the
slave address of endpoint A. Thus, bi-directional transfer of MCTP packets requires that both sides of the
communication have slave addresses.
It said that both end points A and B have to take the role of masters. But how will block transfers operate if end points A and B are both bound by the i2c controller? Why can't end points A always act as master and B always act as slave, respectively? I agree above lines are applicable for SMBus interface.
Thanks.
|
|
|
Post by pmschoeller on Mar 7, 2023 15:58:32 GMT
Hi, I'm using the SMBus/i2c binding specification over mctp. I believe there would not be a transfer like a block transfer in i2c if that were the preferred binding.Lines from 6.11.1 Slave addresses are shown below. 6.11.1 Slave addresses
Each device on SMBus/I 399 2C shall have a slave address to be the target of transactions by bus masters. The MCTP transport protocol solely utilizes Master Write transactions to transfer MCTP packets between MCTP endpoints. For endpoint "A" to send an MCTP packet to endpoint "B", endpoint A shall master the
bus and issue a Block-Write transaction to the slave address of endpoint B. Similarly, for endpoint B to
send an MCTP packet to endpoint A, it shall master the bus and issue a Block-Write transaction to the
slave address of endpoint A. Thus, bi-directional transfer of MCTP packets requires that both sides of the communication have slave addresses. It said that both end points A and B have to take the role of masters. But how will block transfers operate if end points A and B are both bound by the i2c controller? Why can't end points A always act as master and B always act as slave, respectively? I agree above lines are applicable for SMBus interface.
Thanks. First, I apologize for such a long delay to your question. I am going to directly answer your questions and then provide historical context of how the decision to use SMBus Block Write transactions was made. How will block transfers operate if end points A and B are both bound by the i2c controller? I feel like this could be a limitation in your specific device. When you say endpoints A and B are both bound by the I2C controller, this is not a clear statement. Each endpoint has its own I2C controller in the device and are connected by a two-wire interface (TWI) which is Clock (SCL) and Data (SDA). All recent (e.g. 2015+) ARM and Programmable Integrated Circuit (PIC) controllers I have used can support both Master and Slave mode and even newer controllers have SMBus 2.0 Protocol enabled in the I2C controller. The SMBus 2.0 Protocol Specification has a strict definition of how an I2C Master obtains ownership of the bus and how to recover from bus ownership collisions. I have implemented a full MCTP enabled stack on a MCHP PIC24 over SMBus and only used a single I2C interface. The logic is fairly straight forward and simply requires a sense of state of being in the "Waiting for a request" and "Responding to a Request". The MCHP PIC24, for example, has full DMA capability to the I2C controller so the entire MCTP packet and be created in a memory buffer and then simply transferred using the controller. Why can't end points A always act as master and B always act as slave, respectively?The reason the Request message and Response message are separated is to meet the SMBus 2.0 timing constraints as well as to allow more complex data, typically taking a longer retrieval time than a simple "register offset collection". By having both MCTP endpoints use SMBus Block Write transactions, the requestor is free to perform other activity until the response is sent rather than be stuck on the I2C Bus with a Clock Extend. Modern Baseboard Management Controllers (BMC) perform a lot of different operations and need to have free compute cycles to service other tasks and a lot can be accomplish More details in the Historical Context. Historical Context:The MCTP Binding over SMBus 2.0 (DSP0237) works similar to the IPMI IPMB transport protocol which was also a multimaster protocol. One of the reasons MCTP chose to create two independent transactions is the limitation of 25ms total CUMULATIVE Clock (stretch) Extend for the entire SMBus Transaction starting from the START and ending with the STOP condition. As you will see in DSP0237, Table 9 – Timing specifications for MCTP control messages on SMBus, the minimum timings are 100ms for responses and other latency. This is 4x the maximum clock extend allows by SMBUs 2.0 / SMBus 3.0. The timings for base MCTP Control messages is aligned to other MCTP Message (payloads) which allow the responder sufficient time to retrieve the data for the response, create the response message and then send the response to the requestor. So from an industry standard specification compliance view, the original architects of MCTP did not believe that a SMBUS Block Write - Block Read transaction would be able to meet the SMBUs 2.0 Specification timing constraints. Historically, the SMBus 2.0 Specification was authored in 2000 to address some of the limitations of the I2C physical bus. A protocol was added on top of the physical I2C protocol (SCL / SDA) to provide a method to dynamically assign slave addresses to resolve conflicts as well as a specific mechanism to obtain the slave address from a device (SMBus Get UDID(General) command). The technology in 2000 was more silicon based with a transaction write to an offset (e.g. 0x10) and read back one or more bytes but typically less than 16 at 100KHz. Today, the I2C Bus is typically operating at 400KHz and is transporting (with MCTP) much larger messages which are transported using fixed length packets. The Baseline Transmission Unit (BTU) is set to 64 bytes for the MCTP Message (or Payload). This BTU allows the requester and the responder sufficient time to transmit an MCTP packet on SMBus 2.0 and meet the specified 25ms cumulative clock extend.
|
|
|
Post by techenthuist on Mar 31, 2023 4:32:32 GMT
Okay Thanks for the explanation. What's the significance of 'Destination Slave Address' byte in MCTP packet ? Is there a scenario which clearly explains the usage of 'Destination slave Address'?
|
|
|
Post by pmschoeller on Apr 18, 2023 14:28:22 GMT
Okay Thanks for the explanation. What's the significance of 'Destination Slave Address' byte in MCTP packet ? Is there a scenario which clearly explains the usage of 'Destination slave Address'? I am not sure I understand your question but I assume you are referring to DSP0237 MCTP SMBus/I2C Transport Binding Specification, Section 6.3 MCTP packet encapsulation. The first 4 bytes of the MCTP transaction over SMBus are the SMBus 2.0 header, which is described in the SMBus 2.0 specification. The SMBus 2.0 "Destination Slave Address (DSA)" (which is now referred to as the Destination Target Address (DTA)) is the "address" of the device which will accept a targeted message. This is documented in the SMBus 2.0 protocol specification which also specifies the Two-Wire Interface (TWI) physical layer protocol also known as I2C. These 4 bytes are defined as the SMBus Block Write command. The MCTP is bound to the SMBus Block Write command as described in DSP0237 which normatively states: - The Command Byte shall be 0Fh
- The byte following the 'Byte Count' field shall be the source address with R/W Bit set to 1'b1.
- The transaction shall have an SMBus 2.0 Packet Error Check.
Historically, the SMBus 2.0 Specification (authored in 2000) to address some of the limitations of the I2C physical bus. A protocol was added on top of the physical I2C protocol (SCL / SDA) to provide a method to dynamically assign slave addresses to resolve conflicts as well as a specific mechanism to obtain the slave address from a device (SMBus Get UDID(General) command). For the MCTP Bus Owner (whose function is described in DSP0236 MCTP Base Specification) for the SMBus, which is typically the Baseboard Management Controller (BMC), the MCTP Bus Owner can send the SMBus Get UDID (General) Command to every SMBus enabled device. This command is described in the SMBus 2.0 Specification. The MCTP Endpoint (over SMBus Binding in this case) will receive the requester (sending) Destination Target Address (DTA) in the request (from the byte following the 'byte count" field and clears the R/W bit) to send the response to the requester. Have you reviewed the DSP2015 - Platform Management Communications Infrastructure (PMCI) Architecture White Paper document? This describes the foundational layers that MCTP is built upon. To enable a SMBus 2.0 MCTP Bus Owner, an understanding of the SMBus 2.0 Specification is required. The first 4 bytes shows in the MCTP transaction over SMBus 2.0 (binding) which includes the Destination Target Address (DTA). The DSP2015 Specification provides an good overview of how the PMCI WG standards layer on top of other industry standard specifications. I hope this detailed explanation helps you on your implementation.
|
|