# How SPI and I2C latch data?

I got questions about the working mechanism and measurement method of SPI and I2C interface. For SPI, there are several modes. My question is, how will the data be latched? Take CPOL=1 and CPHA=0 for example, the bit is latched at the falling edge of clock. But, why is it the same for MISO and MOSI? I mean, MISO and MOSI come from different devices(the former from device and the later from master). But the clock always come from master. So how would it possible to latch both MOSI and MISO by the falling edge of clock? For MOSI maybe yes, since the clock and the MOSI output together from master, and arrive device at the same time (maybe I should say half clock later). So it's possible for MOSI to follow the timing diagram. But for MISO, how do we let the MISO be latched at the center of its bit, since it'll travel an uncertain flight time from device to master? And for scope measurement, which point should we probe? MOSI on device side and MISO on master side?

I got the same question on I2C. How to make sure the SDA data will be kept high when it's from master to slave, and from slave to master, since the clock is always from master to slave?

Thanks for any feedback! :)

• do you find any issue using SPI/I2C in your project, or you are asking this for learning purpose?
– Raj
Feb 13, 2017 at 7:46
• Hi Raj, just learning purpose..... :) Feb 13, 2017 at 7:48

So how would it possible to latch both MOSI and MISO by the falling edge of clock?

The diagram are meant for illustration purpose only not a detailed one inside the chip, let us assume the data is capture on falling edge, assume the slave is transmitting data, now on the falling edge of the clock, the slave output the bit (say MSB on first clock), the output will be held by the slave till rising edge of the CLK input, master can allow the slave data till the rising edge of the CLK and then shift the bit right, the same repeat till all data bits are received, the same apply to MOSI from master.

Another, explanation using SS (slave Select also called Frame Synchronization I/O Pulse), when SS bit goes low (see the picture) the slave out put the data, on falling edge the data is captured which is approximately center of the data pulse on rising edge next data is shifted to the output, so we have CLK pulse width time for data to settle in the output pins and master to capture the data from slave

SPI peripheral module will have all necessary timing, shifting circuit to make it functional on worst case situation.

• Hi @Raj: Thanks for your explanation! Can we use the last diagram I attached for example? It's a timing diagram from a device(actually a SPI flash chip). 9.7 is the "read" timing, and 9.8 is the write timing. For read, the timing which is specified is tCLQX and tCLQV, which is clock falling edge to data valid(or hold time). For write, the timing which is specified is tDVCH and tCHDX, which uses clock rising edge as the judgement of setup/hold time. Is there any reason why the chip spec define such parameter? Feb 13, 2017 at 9:13
• since the data moves/comes in from external to the chip the input should adhere to this timing, else the data transfer will prone to errors, normal distance of cable should be between 10-15 meters. If you increase the cable length this may affect the timings of the clock and data, as far as the timing signal are within the specified rise fall time the device will function as expected
– Raj
Feb 13, 2017 at 9:21
• Hi @Raj, I think my question would be, why read and write define different edge of clock to data? For master read, can I understand this way: the device only guarantee that the data would be output in a certain time after clock falling edge, and the master should take care of itself to latch this data back? and for master write, the device only guarantee that if the input data satisfy the setup/hold time based on rising clock, and the data will be latched correctly in the device? Thanks! :) Feb 13, 2017 at 9:38
• But there comes another question, for master read, the data read back to master, looks like it should be latched in master with the rising edge, but there is no timing spec to specify the setup/hold time of the master read. Do you know why? Feb 13, 2017 at 9:43
• @david, see the diagram 2 serial input timing, CS(SS/Synchronous) signal is held low to synchronous with the slave timing, note the clock is moved high before CS and after tCHSL time it is set to low, on the falling edge the slave output the data in MISO, the data is latched to master shift register ion the rising edge (the timing signal is meant for rising edge CLK)
– Raj
Feb 13, 2017 at 10:33

SPI and I2C are relatively slow interfaces, designed to work with dumb slaves and a single active master. This means you have to pick a clock speed that's compatible with the path lengths and the circuitry involved.

The clock to data round trip time must be taken into account when designing the circuitry for the interface. If the interface involves optical isolation, and cheap ones can be slow (it's tough to meet even 100kHz I2C with CNY17's in the path), then these have to be taken into account as well. Read the datasheets for any buffers you are using, calculate RC time constants, do your homework, and allow 5nS per metre for any transmission line delays as well. Add up all the propagation times, subtract from half a clock cycle, and see if it meets the interface setup time ($t_{su}$, it's on the data sheet), if >0, result happiness.

High speed interfaces tend to be Source Synchronous for this very reason, all signals are sent from the transmitting end.

Very High Speed interfaces like SATA, HDMI etc do away with the need for synchronisation of any signals at all, and send data as self-clocked serial.

• Hi @Neil_UK , thanks for your feedback! So you mean that, as the picture I attached now, that the setup time and hold time for 1 and 2 should be satisfied at the same time, by choosing a proper clock speed, is that correct? Thanks! :) Feb 13, 2017 at 7:26
• Another question is that as I attached the spec timing chart, it specifies the output with clock falling edge, but use clock rising edge for serial input. It seems not the same as the CPHA mode. Do you know why the datasheet define that? Feb 13, 2017 at 7:52
• I've not looked at all modes, only detailed sums for the ones I use. But the answer's the same, buckle down and RTFM. Feb 13, 2017 at 8:01