Specification for I3C Vendor-Specific Extended Capabilities¶

This chapter is the normative specification of the Vendor-Specific Extended Capabilities for the I3C Controller as per section 7.7.13 of the I3C HCI Specification.

Security¶

The original HCI specification defines Extended Capabilities as a list of linked lists, which can be discovered from software through a series of CSR reads. This mechanism is unacceptable for the Recovery Mode as memory offsets must be known at synthesis time. Implementation based on this specification should provide a list of known memory offsets for each of the Extended Capabilities.

Extended Capabilities¶

Standby Controller Mode (ID=0x12)¶

The Standby Controller Mode follows the I3C HCI Specification:

• Chapter 6 Theory of Operation

  • Section 6.17 Standby Controller Mode

• Chapter 7 Register Interface

  • Section 7.7.11 Standby Controller Mode

Vendor-specific Extended Capabilities¶

This specification provides definitions and descriptions of the following Capabilities:

• Controller Config

• Standby Controller Mode

• Secure Firmware Recovery Interface

• Target Transaction Interface

• SoC Management Interface

Controller Config (ID=0x02)¶

The Controller Config Capability follows section 7.7.3 of the I3C HCI Specification.

Secure Firmware Recovery Interface (ID=0xC0)¶

This section is based on the Open Compute Project Secure Firmware Recovery, Version 1.0 and the I3C Target Recovery Specification.

The EXTCAP_HEADER is located at the SEC_FW_RECOVERY_OFFSET memory offset. The registers are aligned to DWORD size (4 bytes), unless specified otherwise.

SoC Management Interface (ID=0xC1)¶

The SoC Management Interface is provided to enable additional configuration capabilities to the system integrator, e.g. programmability of PHY Devices.

Features may include programmability of:

• High Keeper strength and enable

• Push-pull driver strength

  • Slew rate control

• Open-drain driver strength

  • Slew rate control

• Calibration of the on-chip resistor

The SOC_MGMT_EXTCAP_HEADER is located at the SOC_MGMT_SECTION_OFFSET memory offset. The registers are aligned to DWORD size (4 bytes), unless specified otherwise.

Details of the operation are implementation specific. It is permissible to implement all registers as generic RW registers.

Target Transaction Interface (ID=0xC4)¶

The Target Transaction Interface (TTI) provides additional registers and queues to enable data flow for Devices configured in the Target Mode. This specification is meant for Standby Controllers which are capable of operating in Target Mode, therefore implementations are required to advertise the TTI by setting the Target_XACT_SUPPORT field of STBY_CR_CAPABILITIES.

Motivation and design choices (informative)¶

• Width of the interface

  • This TTI will be integrated in an SoC with 64b AXI as the System Bus

  • CSRs in the I3C HCI specification are 32b wide, so it makes sense to use the same width

  • Each System Bus read could potentially hold 2 CSRs

    • Recommended Do not use the upper half of the word

    • Optimized Read 2 CSRs (this specification does not define how to handle region boundaries and resulting errors)

  • TTI Queues will also be 32b wide for the same reason

• Communication scenarios with I3C Devices

  • When a valid I3C frame appears and the RnW bit is set to Read, then Device has a timing constraint on providing valid data

    • Typically, this is not a problem for simple sensors, which can prepopulate data

    • Problem for a SoC

      • Unknown response latency over System Bus

      • Unknown ISR processing latency

    • I2C solves this issue by using Clock Stretching by Target

      • Prohibited by I3C Basic Specification

    • I3C allows the Controller to stretch Clock (Section 5.1.2.5, I3C Basic)

      • Does not alleviate Target side timing issues

  • There are 2 designs which are considered here to increase robustness

    • Write-first approach: Before each Read from this Device, a Write is issued to inform Target to prepare the payload

      • Timing issue may still appear, but the timing budget is larger by a factor of (transfer length / bit length)

    • Write-first Expect-IBI: Reads are only performed based on an IBI with Pending Read Notification (Section 5.1.6.2.2, I3C Basic). Reads occur only when the Target Device has valid data, completely solves the timing issue, assuming that data length does not exceed buffer length.

Boot¶

The Target Device boots with bus operation disabled as per description of the STBY_CR_ENABLE_INT field in the STBY_CR_CONTROL register (section 7.7.11.1)

Initialization¶

The software is responsible for setting the TARGET_XACT_ENABLE bit in the STBY_CR_CONTROL register.

Operation¶

TTI is used to handle generic Read-Type and Write-Type transactions sent by the Active Controller on the I3C bus. In this mode, software is responsible for servicing TX and RX queues based on the interrupt signals.

There are 5 queues to communicate between the bus and the register interface:

• TX Descriptor queue, which holds information about the write transfer

• TX Data queue to buffer data written from the Target Device to the bus

• RX Descriptor queue, which holds information about the read transfer

• RX Data queue to buffer data read from the bus by the Target Device

• IBI queue to buffer data which will be written to the Bus as an In-Band Interrupt

Bus Read Transaction¶

After the Bus Read Transaction is acknowledged by the Target Device, it performs a write to the Interrupt Register to inform software of a pending read transaction. Software writes the response data to the TX queue and the TX descriptor to the TTI TX Descriptor queue.

Bus Write Transaction¶

The Bus Write Transaction is acknowledged by the Device if the transaction address matches the Device address and the R/W bit is set to 1. The Target Device writes incoming bytes to the TTI RX Data Queue. After the transaction ends, a TTI RX Descriptor is generated and pushed to the TTI RX Descriptor Queue for the software access.

If an Active Controller writes more data to the Target Device than it is capable to handle (even with triggering interrupts on threshold), the generated TTI RX Descriptor should indicate an error status and the Target Device should not ACK data on the bus. The Active Controller can attempt mitigating such a situation by reading Target queue size from the TTI_QUEUE_SIZE register before sending a big chunk of data.

In-Band Interrupts¶

The Controller expects to receive an IBI Status Descriptor which is then followed by consecutive DWORDs of IBI Data. The IBI Status Descriptor should be compliant with section “8.6 IBI Status Descriptor” of the MIPI I3C HCI specification v1.2. If the IBI requires more data to be sent than it is allowed in a single chunk, it should be split into multiple IBI transfers with the LAST_STATUS IBI Descriptor field set to 0, unless it is the last one.

Register Interface¶

The TTI_EXTCAP_HEADER is located at the TTI_SECTION_OFFSET memory offset. The registers are aligned to DWORD size (4 bytes), unless specified otherwise.

TTI_CONTROL Register¶

TTI_STATUS Register¶

TTI_RESET_CONTROL Register¶

TTI_INTERRUPT_STATUS Register¶

The status fields are either R/W1C (write 1 to clear), or else are cleared based on queue operations.

TTI_INTERRUPT_ENABLE Register¶

TTI_INTERRUPT_FORCE Register¶

TTI_RX_DESC_QUEUE_PORT Register¶

TTI_RX_DATA_PORT Register¶

TTI_TX_DESC_QUEUE_PORT Register¶

TTI_TX_DATA_PORT Register¶

TTI_QUEUE_SIZE Register¶

TTI_IBI_QUEUE_SIZE Register¶

TTI_QUEUE_THLD_CONTROL Register¶

TTI_DATA_BUFFER_THLD_CONTROL Register¶

Target Transaction Interface TX Descriptor¶

Target Transaction Interface RX Descriptor¶

TTI Queues¶

TTI TX Descriptor, TTI TX Data, TTI RX Descriptor, TTI RX Data and TTI IBI queues should be implemented as FIFO queues of 32 bit (1 DWORD) width. Depth should be parametrizable and the TTI_QUEUE_SIZE register’s reset value should be set accordingly. In order to prevent overflow/underrun scenarios, a programmable threshold signal is provided. Software-issued reset of the queues contents is also possible.

Errors¶

1. [Generic Read] Device didn’t have data in time to respond to the controller

   1. Action taken by hardware

      1. NACK the next byte of data

      2. Report Error in the Error Register

      3. Raise ERR_IRQ

   2. Action taken by software

      1. Prepare an IBI with Pending Read Notification

      2. If MCTP, then use 5’h0E Interrupt Identifier (Section 5.1.6.2.1, I3C Basic)

2. [Generic Write] Device was overrun

   1. Prevention mechanisms

      1. Active Controller should use SETMWL, SETMRL based on realistically set GETMWL, GETMRL values

   2. Action taken by hardware

      1. NACK the next byte of data

      2. Report Error in the Error Register

      3. Raise ERR_IRQ

   3. Action taken by software

      1. Prepare an IBI with Error Type Notification

         1. Can use the 5’h0D Interrupt Identifier (Section 5.1.6.2.1, I3C Basic)

Ideas for the future (informative)¶

• Add Debug EC

• Virtual TTI

  • Consider reusing existing CSRs from Active Controller in this way

• MCTP Binding