Programmer’s Guide

Buffer allocation

The I3C IP block uses a single shared SRAM, the ‘message buffer’, to implement all of the logical queues and data FIFOs within the design, including both the Controller and the Target sides.

The allocation of this buffer is entirely under software control, and should be determined by which queues and FIFOs are being used, along with their anticipated data rates. The configuration must be set before enabling either Controller or Target operation.

The hardware provides a default configuration so that the IP block is operable after coming out of reset, even if the configuration has not been modified. It should, however, be noted that this configuration is conservative and anticipates the heaviest use case with all supported Virtual Targets configured and used; if fewer Virtual Targets are activated, the configuration should be modified to achieve better use of the memory.

The default buffer allocation, with the queues and FIFOs arranged in ascending order of buffer offset (in DWORDs) is shown below:

Each of the queues/FIFOs has a configuration register that specifies the minimum and maximum offsets, in DWORDs, within the message buffer. Both offsets are inclusive and it is the responsibility of the software to ensure overlaps do not occur because otherwise undefined behavior will result.

Timer Intervals

The IP block contains a number of timers for measuring the duration of I3C bus states, such as the ‘Bus Available’ and ‘Bus Idle’ conditions. The longest of these time intervals is the 50ms ‘Dead Bus Recovery’ interval, whilst the shortest interval is the ‘Bus Available’ condition at just 1 microsecond.

In order to support this wide variation in time intervals across the large range of supported IP clock frequencies, the timer granularity (in IP clock cycles) varies on a per-timer basis as illustrated by the following tables, at the extremes of the supported clock frequency range.

Minimum supported clock frequency, 50MHz:

Maximum supported clock frequency, 1.5GHz

All times are quoted to two significant figures. It may be seen from the above tables how the shift amount achieves almost exactly the same granularity of timer adjustment despite the large disparity in IP clock frequency.

The timers are independent of each other and share no logic or synchronization beyond the fact that they are all updated by the single IP clock signal.

If the hardware-calculated default interval is found to be inadequate, e.g. in the event of oscillator frequency inaccuracy, an adjustment may be made by software using the appropriate field of INTERVAL_TIME0 or INTERVAL_TIME1 as illustrated below. The adjustment values are reset to 0, meaning that the unmodified default interval is used.

Time intervals are specified as two’s complement 8-bit signed offsets added to the default values calculated by the hardware:

• interval_clks = (hw_default_us * clks_per_us) + (signed_adj << shift)

The shift values, as illustrated in the tables above, are adjusted according to log2(clks_per_us) with the result that the adjustment has about the same time range, irrespective of the IP clock frequency.

Clock frequencies:

• 50MHz to 64MHz, both inclusive: base weighting applies and the shift value are as shown in the 50MHz table above.
• From 64MHz (exclusive) to 128MHz (inclusive): adjustments have twice the base weighting; shifts are increased by 1.
• From 128MHz (excl.) to 256MHz (incl.): adjustments have 4 times the base weighting; shifts are increased by 2…
• From 256MHz (excl.) to 512MHz (incl.): adjustments have 8 times the base weighting.
• From 512MHz (excl.) to 1024MHz (incl.): adjustments have 16 times the base weighting.
• From 1024MHz (excl.) to 1500MHz (incl.): adjustments have 32 times the base weighting; shifts are increased by 5.

IBI Payload Fetching

A number of I3C Targets are too slow to be able to return data for Private Read transfers at the full SDR0/HDR-DDR signaling speed.

When the Host Controller is issuing a Private Read transfer, the signaling mode/rate is specified in a Command Descriptor, but when fetching the payload data for an In-Band Interrupt, there is no Command Descriptor available so the hardware cannot determine the required signaling speed.

The HCI Specification does, however, allow the specification of a signaling mode for ‘Auto-Command’ reads (HCI Table 130, AUTOCMD_MODE field), so this IP block also uses the value in that field when fetching the IBI payload data. If that field has been set to HDR-DDR for Auto-Command operation, the IBI Payload of the device will be fetched with SDR0 signaling, since IBIs are not supported in HDR modes.

If a Target is known, through retrieval of its maxRd value (4.3.7.3.18), to be too slow to support SDR0 signaling, the AUTOCMD_MODE of its DAT entry should be set to a lower signaling speed before the collection of In-Band Interrupt payloads from that Target is enabled.