SPI Storm 50MHz Serial Protocol Host Adapter

The SPI Storm is the first high-speed SPI Adapter that also supports Dual- and Quad- SPI protocols. In addition, virtually any custom serial protocol up to 50 MHz can be set up with its advanced protocol definition engine. SPI Storm is a high-speed Serial Protocol Host Adapter used for chips and electronic board stimulation with serial protocols and digital patterns. It operates on standard SPI protocol, Dual-SPI, Quad-SPI and custom serial protocol interfaces including three-wire interfaces with bidirectional data lines.  The SPI Storm also supports open-drain output signaling.

The SPI Storm is delivered with the SPI Storm Studio(TM) control software with graphical user interface and direct C/C++ DLL access.

"With the SPI Storm, we observed the highest effective data throughput we have seen on any USB-connected SPI adapter..." - says a customer.

Setting up serial protocol with SPI Storm Studio

This is the primary step for using SPI Storm device. It consists in describing how you would like to access your serial device: whether you would like to write to your device, read from it or do both simultaneously. Which serial protocol would you like to to use? What are the specifics of it?

Defining MACROS

‘Macros’ are formatted commands that you can call independently to access your device under tests. For instance one given macro is a 8-bit long SPI access with SCLK running at 10 MHz and where SS2 is used as active-low signal. Another macro could be composed of a single SPI access immediately followed with a Quad-SPI write command (see illustrations below).

8-bit standard SPI access

Access composed of a standard SPI followed with a Quad-SPI write

Standard or custom protocol?

As unique feature, SPI Storm Studio allows using standard, built-in serial protocols or defining custom protocols.

‘Standard protocols’ are pre-configured protocols delivered with SPI Storm Studio:

• SPI (Serial Peripheral Interface): 4 wires protocols using MOSI, MISO, SCLK and SS.
• SPI-3 : variant of the SPI protocol where MOSI and MISO are merged as a single bi-directional data line, with bus turn-around phases.
• Dual-SPI : variant of the SPI protocol that includes modes in which 2 data lines are used for conveying data.
• Quad-SPI : variant of the SPI protocol that includes modes in which 4 data lines are used for conveying data.

Parameters like read / write bit length, signal polarities, clock frequency and characteristics can be specified.

SPI Storm Studio’s Custom Protocol Definition Engine is delivered with ALL SPI Storm device versions. Using this engine helps covering more access cases:

• Communication protocols that slightly differ from SPI. Specific SPI slaves sometimes require a delay between the assertion of SS and the start of the clock.
• Complex write and read commands that only use 1 data line for read and write. In such a case, the master must be able to manage sequences of commands with bus direction change
• Quad-SPI-like protocols that use up to 4 data lines to reach higher total throughput.
• Clock tick count-based protocols: some protocols require a very tight control of the clock with deterministic timings between the accesses
• Protocols with open-drain I/Os
  
  
  
  
  
  
  
  … and many other cases…

How to use a standard protocol?

Standard protocols are pre-formatted protocols available from SPI Storm Studio.

Each standard protocol defines a ‘canvas’ for write and read accesses: when the device will write and/or sample it, the physical data lines used for the protocol, when the clock is IDLE or active, and so on.

SPI Storm Studio proposes 4 ‘standard protocols’: SPI-4 (standard SPI), SPI-3 (standard SPI with a signal bi-directional data line), Dual-SPI and Quad-SPI protocols.

A limited number of parameters must be defined for using each protocol. They are shown on the figure to the left.

Did you know?

You can see for yourself how protocols are defined with SPI Storm Studio. Simply download and install SPI Storm Studio for free: you just need a license when you actually want to use SPI Storm hardware.

How to define a custom protocol?

SPI Storm Studio’s unique protocol definition engine lets you define your own write and read commands.

Each protocol can be defined as a sequence of ‘segments’ with specific properties:

• Whether the clock signal is running or held at a constant level;
• The usage of each data line: output, input, unused; constant or variable;
• The length of each segment,…

Segments are the ‘building bricks’ for defining the commands (macros) used to communicate with your slave.

SPI Storm Studio software allows assembling the segments as sequences, so you are able to:

• Re-use protocols segments within the same macro or in multiple macros;
• Define protocol with a clock period resolution (up to 10 ns resolution);
• Implement complex command involving data generation and sampling;
• Carefully control how you communicate with your embedded system, or digital IC.

Building up sequences with SPI Storm Studio

Once you have defined your collection of commands (macros), you need to call them. You can build sequences of macros with the SPI Storm Studio built-in graphical ‘Program’ builder or use the provided C/C++ API.

SPI Storm Studio’s graphical interface allows building sequences that call the macros defined in your library. When applicable, variable macro fields such as output data can be provided by simply entering a list of value in the GUI or by referencing an external file containing the values. Similarly, sampled input data is saved to a separate file.

From the C/C++ API, you can run a program defined with the GUI or call each macro that you saved in your project file (.ssp). Each macro is defined with pointers to data structures, allowing direct output / input data processing without having to save to a file first.

Did you know?

In addition to the serial interface, you have a 8-bit GPO (General-purpose output) to generate arbitrary digital patterns. GPO patterns can be synchronized with the serial interface. Digital patterns are defined as segments and macros. They can be sourced from an external file or entered in the GUI directly.

Running program & Retrieving data with SPI Storm Studio

Once macros and program are defined, you can execute it and send commands over the physical serial bus. During this step, the SPI Storm device will actually generate clock and the binary data information required on each line and sample the digital lines when requested by the corresponding macros.



Sampled information is collected by the device and transmitted over to your software environment (C/C++ through the API or GUI) and stored into output files.

Did you know?

The program executed by SPI Storm is compiled on the PC and buffered into SPI Storm’s memory. Unless you change global parameters such as clock frequency and phase or I/O characteristics, there will be no latency between your accesses. In other words, if your slave requires a recovery time between accesses, you need to include it in the protocol that you define.