Duke's Blog

SPI is a fundamental synchronous communication interface widely used in applications like MCUs, DACs, sensors, memory, communication controllers, and displays.

High-speed or long-distance SPI transmission faces challenges, especially delays in the slave's response, leading to instability or errors. These delays include:

1. Transmission delay from the master’s clock to the slave.
2. Processing delay within the slave from clock reception to data output.
3. Delay from the slave’s data output to the master’s data read.
4. Additional delays introduced by components like drivers, converters, or isolators.

SPI has four modes based on CPOL (Clock Polarity) and CPHA (Clock Phase). Mode 0 (CPOL = 0, CPHA = 0) is used as an example below.

Figure 1:

In SPI mode 0, both the master and the slave sample data on the rising edge of the SCK. Signals such as SS (or CS), SCK, and SDI (or MOSI) are transmitted by the master, with minimal delay between them.

However, SDO (or MISO) is output by the slave. To ensure the master samples data correctly on the rising edge of SCK, the slave outputs SDO starting at the corresponding falling edge of SCK. Due to the delays mentioned earlier, the SDO signal may lag slightly, with the lag time denoted as Td in the diagram.

In Figure 1, the delay relative to the SCK clock is small and does not affect the master's sampling. For example, when the master samples the D7 data at time Tc, it still occurs near the center of D7.

However, if the SCK clock frequency increases or transmission delays become significant, the waveform observed by the master changes as shown in the diagram below:

Figure 2:

At this point, sampling at Tc fails to capture the correct D7 data.

In such cases, QSPI, a protocol similar to SPI, adopts a solution where the master delays sampling the SDO data by half a clock cycle, effectively sampling at the falling edge of SCK to the right of Tc.

However, most SPI master controllers do not support delayed sampling, and delaying sampling increases transmission time, reducing efficiency.

This article proposes a method where the slave outputs SPI data half a clock cycle earlier. This approach efficiently resolves communication errors caused by SPI response delays.

Specific Implementation:

Figure 3:

The slave begins outputting SDO data at the rising edge of SCK to the left of Tc and updates the SDO data on each subsequent rising edge of SCK.

Although the goal is to output SDO data earlier, in the example, the minimum SPI transfer unit is 8 bits. The slave only fully receives the address or command issued by the host on the rising edge of the last bit of the first transfer unit. At this point, it cannot immediately output the data corresponding to the address or command, as processing the data requires time.

The specific implementation method is to sacrifice the last bit of the host transmission. For example, originally, the highest bit was for read/write selection, and the lower 7 bits were for commands. Now, the middle 6 bits are used for commands, and the lowest bit is ignored (denoted as X in the diagram).

This also has an additional benefit. Originally, there was only half of an SCK cycle to prepare from receiving the complete command to outputting data, but now there is a full SCK cycle. This allows the slave chip's internal circuits to support higher-frequency SCK clocks.

The slave made using this method can be compatible with ordinary SPI masters, which is highly significant.

The slave can also be dynamically configured to output SDO data half a cycle earlier. For example, the slave, upon power-up, defaults to not outputting data early. After the user configures the corresponding register, the early output mode can be enabled.

For cases with very large delays, this method can be used while adding an additional half-cycle delay on the host side to sample the SDO data.

Some devices, such as TI's ADS8684, also use the method of outputting SDO data half a clock cycle earlier. However, since it is difficult to output data immediately upon receiving a complete command, the data corresponding to the current command is only output during the next SPI transfer. This significantly reduces the timeliness of the command.

The specific Verilog code implemented in this article can be found in the next branch of the GitHub repository at https://github.com/dukelec/cdbus, located in the example directory.
This project is the source code for the CDBUS controller chip, such as the CDCTL01A, which enables RS485 to support features like arbitration, allowing for multi-master and peer-to-peer communication, overcoming the limitation of only supporting polling.
For more information, please refer to: https://github.com/dukelec/cdbus_doc.

This work is licensed under a Creative Commons Attribution 4.0 International License.