# SPI chip select --> data + clock delay tolerance

I know this likely depends on the specific chips and devices being used, but I'm just looking for estimate ballpark numbers.

I'm considering using the spi protocol for a project, and I can't seem to find any good timing diagrams, on the time tolerance from the assertion of the chip select till data must be pushed on the data line.

I'd love to be shown such diagrams for different devices, and what seems to be 'standard values', assuming that's a thing.

This is a learning project, electronics is not my main field.

• Have ayou looked at any data sheets? If so which ones (leave a link). Feb 5 '15 at 19:50
• If your issue is lack of IO's to drive chip selects from the master, you can have a state machine (CPLD, fast slave micro) which interprets a few bits of a prefix byte and drives a slave chip select accordingly, then releases it when the master select is released. In software, every time you would drive a slave select you instead drive the master one and send an address byte. Of course your inter-byte (or failing that, inter-bit) timing must satisfy the slave's select setup time after the delay of the offboard decoder is accounted for. Feb 6 '15 at 15:03

It goes the opposite way: the delay must be no shorter than a certain value, usually a couple hundred ns. Moreover, it's the delay between assertion of CS and the first edge of the clock signal. It has nothing to do with the data line at all.

Note that this "delay" can always be infinite. If you have only one slave device, you can typically keep CS permanently asserted, unless there's no other way to recover the inevitable clock slip than cycling CS (think of interference).

The question is, then: are you trying to design an SPI slave, an SPI master, or a system that has both? If you control the master, then you can always guarantee sufficient delay between CS and SCLK - it's a matter of programming it right.

Since your intention is to switch the CS signals manually, you must debounce them. A simple push to toggle implementation is shown below:

simulate this circuit – Schematic created using CircuitLab

You'd need a way to reset all other chip selects when any one of them is activated.

• My consideration was if physical switches for chip select would be possible, as this could result in several seconds or minutes of delay from chip select, to the spi communication initiates, depending on the laziness of the operator. Feb 6 '15 at 11:31
• I'm building the entire system, master and multiple slaves, which I want to chip select. The master chip does not spare output pins for the chip selects. Feb 6 '15 at 11:36
• Why would you need to debounce the chip select? As long as it is stable well before the clock edge, it doesn't seem like there should be a problem. I guess I could imagine a very poorly implemented SPI engine could perhaps get confused (or driven metastable?) by a bunch of null transactions, but that seems like a broken design, more than illegal usage. Feb 6 '15 at 14:53
• @ChrisStratton You need to debounce it because CMOS logic inputs need fast transitions on inputs, or else they'll consume excess power and you can actually exceed the absolute maximum ratings by being cavalier here. If it's a logic input, it needs to adhere to specs, whether it's used at the moment or not. Mechanical switches produce outputs that are never compatible with any sort of a modern logic input. I repeat: never. The debounce circuit I show needs to use Schmitt inputs, I've annotated it so. Feb 6 '15 at 14:56
• No. Your theoretical concern is noted, but the world is chock full of well engineered devices which use switch/pullup combinations to drive ordinary CMOS inputs and accomplish debouncing by selectively ignoring input state further inside. Do you have an example of a data sheet where the minimum slew rate is specified in the absolute maximum ratings, rather than the performance specs? Feb 6 '15 at 15:09

Actually the CS timing is not very important -- you usually assert the CS line (bring it low) at the beginning of a bunch of transfers, and then de-assert it (bring it high) at the end. What is more important is the relationship between the clock (SCK) and the data (SI/SO).

Here is a typical timing diagram for an SPI peripheral, in this case a 2AA1024 1 Mbit serial EEPROM.

In this case, the timing is for writing a byte to the EEPROM.

As you can see, the chip select is brought low at the beginning of the 8-bit transfer and left there. (In general, it can be left low across as many bytes as needed to be read.)

The numbers refer to the timing specifications, usually at a specific voltage. I chose the slowest, which is for 1.8v.

2 CS setup         250 ns
3 CS hold time     500 ns
4 CS disable time   50 ns
5 Data setup time   50 ns
6 Data hold time   100 ns
9 Clock high time  250 ns
10 Clock low time  250 ns


The speed is 2 MHz, or a high/low clock period of 250 ns each (Clock high time, 9 and Clock low time, 10).

So the chip select does need to be asserted for 250 ns before the first rising clock pulse (CS setup, 2), but obviously that is very short if being driven from a microcontroller output.

The data must be present 50 ns before the rising edge of the clock (Data setup, 5), and must remain valid for 100 ns afterwards (Data hold, 6); this will usually be handled automatically by the SPI peripheral, and would only be important if the interface is being "bit-banged".

It should be noted that this diagram assumes that the clocking of data is done on the rising edge of the clock. SPI interfaces can also be configured to clock on the falling edge.

At the end of the transfer, the CS line must be kept low for 500 ns (CS Hold time, 3) after the last clock transition, before being brought high; and must remain high for 50 ns (CS Disable, 4) before it can be asserted again.