Electronic – SPI Flash device selection using SCLK, MOSI as well as SS

flashspi

In a system with N SPI devices it would normally take N+3 pins on the master to communicate with them all (NxSS, SCLK, MOSI, MISO). With N being large and the master device (FPGA) is pin limited, I'm considering the following 2 techniques to increase the number of possible SPI devices in the system; and would like to know if there any (additional) reasons should not be used ? (I've listed reasons I can think of at the end)

Technique 1) Use 'K' SCLK lines (and 'N' SS lines) to effectively "select" NxK devices. Only 1 SCLK line would be active at a time.

  • U1: SCLK1 and SS1 (U2 selected but receives no clock)
  • U2: SCLK2 and SS1 (U1 selected but receives no clock)
  • U3: SCLK1 and SS2 (U4 selected but receives no clock)
  • U4: SCLK2 and SS2 (U3 selected but receives no clock)

schematic

simulate this circuit – Schematic created using CircuitLab

11 lines (MISO, MOSI, 5xSS, 4xSCLK) could operate a 4×5 matrix of 20 devices).

Technique 2) Multiplex MOSI, using 'J' MOSI lines sending null commands to all devices but one, expecting only the targeted device to reply and the others to remain high impedance on MISO.

  • U1: MOSI1 and SS1 (U2 selected but receives null command)
  • U2: MOSI2 and SS1 (U1 selected but receives null command)
  • U3: MOSI1 and SS2 (U4 selected but receives null command)
  • U4: MOSI2 and SS2 (U3 selected but receives null command)

schematic

simulate this circuit

Again, 11 lines could operate a 4×5 matrix of 20 devices.

Using both schemes together, the 11 pins could be used as 4xSS, 3xMOSI, 3xSCLK, 1xMISO, totaling 36 combinations of uniquely selectable devices (virtually selectable). Regarding the Atmel 25M01 serial flash, I can't find any problem with using both of the above schemes. (I know of no SPI master that does this; a custom implementation would be done in a FPGA.)

Concerns I have considered are:

  1. A pulse on SS and not providing a clock might put a slave device into an unknown state, especially if there is activity on MOSI (I doubt it; all "activity" is received via SCLK edges. The Atmel documentation states that the SPI communication scheme is "reinitialized" after every SS cycle)
  2. An active level on SS might already put a chip's MISO in drive mode (Like the Atmel AT25M01 serial flash, I think most chips would wait for a command before coming out of high impedance?).
  3. Sending a NULL command might still invoke a response; in fact there isn't a definition of a "Null" command, only the concept of an "invalid" command. (the Atmel documentation states it will not respond to an invalid command and remain in high impedance)
  4. The design might one day be changed and a different SPI device is added. Do most Flash SPI devices address the above concerns, or am I just lucky with the 25M01?
  5. Some devices such as the Maxim MAX1242 ADC take immediate action solely due to the SS active edge; the ADC starts a conversion on the high→low transition.
  6. Edit: One concern I didn't think of is fan-out. (as mentioned in the answer; I thought it deserved mentioning here)

Best Answer

I think your solution will probably work, within some constraints. The obvious one is "all SPI slaves must exhibit precisely the same bus behaviour as an Atmel 25M01". Also, I far prefer technique 1. Some specific answers:

  1. A PGE on a /CS line should always cause any incomplete bus transaction to terminate immediately, so even if there is the odd spurious clock generated on selected devices that are not the current target they will be cleared in normal operation. Similarly, a /CS window that doesn't enclose any transitions on SCLK shouldn't start any bus transactions.
  2. This is more of an issue. You need to be certain that this won't happen and, as noted, you will need to be clear for maintenance purposes that any new SPI devices don't actively drive the MISO line until they receive a "read" command. You might want to consider fan-out, too; I know high-impedance outputs don't represent much of a load, but 19 of them is worth paying attention to.
  3. If you don't use technique 2, then this doesn't matter...
  4. SPI memory devices, particularly larger ones, are increasingly meeting JEDEC standards for communications behaviour. If you choose devices that are JEDEC-compliant then you should have no interoperability issues, at least until the standards change.
  5. True, but many SPI ADC's actually use the SPI clock to run the ADC's successive approximation state machine. No clock cycles, no output. That said, they might drive the bus immediately. Back to my original point: set a standard, and require that slave devices that don't meet the standard are not attached to the bus matrix.
Related Topic