Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01

Summary
Application Note AP0163 (v2.0) May 15, 2008

This application note describes the SPI communications system on the Desktop NanoBoard NB2DSK01. It covers multiplexed access to the SPI bus and the various SPI-based resources attached to the bus. Interfacing to the SPI bus from an FPGA design is also covered in detail.

After JTAG, the second most important communications system on Altium's Desktop NanoBoard NB2DSK01 involves communications with devices over the Serial Peripheral Interface (SPI) bus. This document takes a closer look at how the SPI bus protocol is used on the NB2DSK01 to facilitate communications with various SPI-compatible resources in the system. For detailed information on the Desktop NanoBoard NB2DSK01, refer to the document TR0143 Technical Reference Manual for Altium's Desktop NanoBoard NB2DSK01. For more information on specifically using an SPI Flash memory device, refer to the document AP0162 Utilizing the SPI Flash Memory on the Desktop NanoBoard NB2DSK01.

SPI Background
Before discussing SPI communications in terms of the NB2DSK01, it is worth taking a quick look at the SPI bus itself, and the constituent signals involved. The SPI bus is a full-duplex, synchronous serial data link, that provides an efficient, low-cost communications solution. Like I2C, SPI provides good support for communications with low-speed peripheral devices, though is capable of higher data speeds than I2C. At the simplest level, SPI communications consists of a single bus master connected to a single bus slave (Figure 1). The bus itself involves four signals: SCLK Serial Clock, generated by the master. DIN Serial Data Input. This is the data written to the slave SPI-compatible device. Data is shifted into the device on the rising edge of the serial clock. DOUT Serial Data Output. This is the data read from the slave SPI-compatible device. Data is shifted out of the device on the falling edge of the serial clock. CS - Chip Select for the slave SPI-compatible device. When the master activates this signal (active Low), the slave device is enabled for communications.
Master SPI Device
SCLK DIN

Master SPI Device

DOUT CS

Slave SPI Device

Figure 1. SPI communications between master and single slave.

SCLK DIN DOUT

Slave SPI Device 1

CS1

Slave SPI Device 2

CS2

Note: DIN and DOUT refer to direction from the slave device perspective. These signals are often seen in literature as MOSI and MISO respectively. For each additional slave device added to the communications system, the SCLK, DOUT and DIN lines are shared. The bus master simply needs to generate a separate device select line for each slave (Figure 2). By activating a single select line and keeping all others inactive, the master is able to communicate with the required slave over the shared SPI bus.
AP0163 (v2.0) May 15, 2008

Slave SPI Device 3

CS3

Figure 2. SPI communications between master and multiple slaves.

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01

NB2DSK01 SPI System Overview

The NB2DSK01 SPI system involves a variety of SPI-compatible slave resources, located across the hardware system on the NB2DSK01 motherboard itself and also on certain peripheral boards that plug in to the motherboard. These SPI resources are accessible by three distinct SPI masters: Altium Designer (via the parallel or USB connection) The firmware more specifically a TSK3000A processor therein loaded onto the motherboard's Spartan-3 FPGA device (the NanoTalk Controller) The design loaded onto the currently plugged-in daughter board FPGA device.

Providing the required SPI bus arbitration between the masters, and access to the SPI devices, is the NB2DSK01's SPI Controller. The Controller, which is part of the NanoBoard firmware, plays the role of multiplexer/router determining which master has access to the SPI bus and which SPI slave device is selected for communications. Figure 3 illustrates the SPI communications system in-place for the NB2DSK01.

Altium Designer

NB2DSK01 Motherboard
Flash Memory (Embedded) Flash Memory (Embedded/ FPGA Boot)

FLASH2_CS_N

FLASH1_CS_N

Board Clock

CLKGEN_CS_N

RTC

RTC_CS_N

Touch Screen Digitizer

TFT_SPI_CS_N

SPI Controller T S K 3 0 0 0 A

DIN DOUT SCLK SEL ADDR[4..0]

Peripheral Board A
SPI Device 1 SPI Device 2 EXTSPI_CSA_N0 EXTSPI_CSA_N1

Device Selection

NanoTalk Controller (Spartan-3 FPGA) Peripheral Board B

SPI Device 1 SPI Device 2 EXTSPI_CSB_N0 EXTSPI_CSB_N1

Daughter Board

F P G A

Peripheral Board C
Mode SPI FLASH2_CS_N FLASH1_CS_N CLKGEN_CS_N RTC_CS_N TFT_SPI_CS_N EXTSPI_CSA_N[1..0] EXTSPI_CSB_N[1..0] EXTSPI_CSC_N[1..0] SPI Device 1 SPI Device 2 EXTSPI_CSC_N0 EXTSPI_CSC_N1

Figure 3. SPI communications on the NB2DSK01.

AP0163 (v2.0) May 15, 2008

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01

Accessing the SPI Bus from an FPGA Design

From an FPGA design perspective, the NB2DSK01's SPI Controller provides an SPI path from the daughter board to each of the SPI slave resources resident in the system. Daughter board connector signals DAU_SPI_DIN, DAU_SPI_DOUT, DAU_SPI_CLK, DAU_SPI_SEL and DAU_SPI_MODE provide this connectivity (Figure 4).

SPI Controller (within NanoTalk Controller Spartan-3 FPGA)

DAU_SPI_DOUT DAU_SPI_DIN

DOUT DIN SPI Address Register & Bus Routing SCLK SEL ADDR[4..0] To SPI Bus and Device Multiplexers

Daughter Board FPGA

DAU_SPI_CLK DAU_SPI_SEL DAU_SPI_MODE

Figure 4. Handling of SPI-related signals from the FPGA design.

During operation, the daughter board FPGA design communicates with the NB2DSK01's SPI Controller to establish a path between the design and a specific motherboard/peripheral board SPI device. Communications with the target device is a twostage process: Firstly, the address of the target SPI device must be written to an address register within the SPI Controller and bus ownership must be requested. Secondly, once ownership of the SPI bus is granted, the SPI lines from the daughter board FPGA must be routed to the external SPI bus itself, and the select line for the required slave device made active.

In terms of communication with the SPI Controller, the FPGA design has two modes of access either accessing and writing to the Controller itself, or communicating directly with a selected target device over the routed SPI bus. The following sections look more closely at how the daughter board FPGA can switch between these two modes, obtain ownership of the SPI bus, select a device for communications, and release the bus after it has finished with the slave device.

Mode of Access
As mentioned previously, the design running in the daughter board FPGA can either access the SPI Controller itself, or the SPI bus directly. These two modes of access are determined by the level of the DAU_SPI_MODE signal: DAU_SPI_MODE = High communicate with the SPI Controller and, more specifically, an 8-bit SPI device address register therein. DAU_SPI_MODE = Low communicate directly with a slave device over the SPI bus.

Getting Ownership of the SPI Bus

Only one of the three bus masters Altium Designer, firmware, or daughter board FPGA can access an SPI device at any one time. Therefore the SPI Controller in the firmware provides simple multiplexed access to the external SPI bus. Arbitration of the masters who has control of the bus at any given time is achieved by employing the notion of 'bus ownership'. Each of the three masters may request ownership of the bus. The job of bus arbitration for the SPI Controller therefore becomes two-fold: Monitor bus requests from each master and grant ownership to one Route the internal SPI lines, from the master that is granted ownership, to the external SPI bus.

Ownership will only be granted provided the external SPI bus is currently not being used. This allows any current transmission on the bus to terminate naturally without any errors. If multiple requests for the bus are present, the following order of ownership hierarchy is adhered to: Altium Designer highest priority Daughter Board Firmware (TSK3000A)

AP0163 (v2.0) May 15, 2008

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01 From the design on the daughter board FPGA, requesting ownership of the SPI bus is performed through the SPI Controller's internal SPI device address register. As described earlier, to access this register you must ensure that the DAU_SPI_MODE line is High. In order to request ownership of the SPI bus, bit 7 of the register must be set ('1'). The register must also be loaded with the address of the device to which you wish to communicate. This address must be stored in bits 4..0 of the register. Addresses for devices commonly accessed from an FPGA design can be found in Table 1 in the section Selecting a Slave SPI Device for Communications. Data transfer on the SPI bus is always MSB first. The 8-bit value you intend to load into the address register is shifted into the register from the DAU_SPI_DOUT line, one bit at a time (from the right), on each rising edge of the DAU_SPI_CLK signal. For example, if you wish to request bus ownership in order to talk to the Touch Screen Digitizer, with address 00101, you must send out the 8 bit value 1xx00101 on the DAU_SPI_DOUT line.

Checking Whether Bus Ownership has been Granted

Putting in a request for the SPI bus does not necessarily mean you will be granted access to it immediately. The bus may be already in use by one of the other masters in the system (Altium Designer or the firmware). To check that bus ownership has been granted, before committing to the actual transmission of data to the target slave device, an SPI send-wait-receive routine is used. After sending out the value to be loaded into the address register on the DAU_SPI_DOUT line, the value received on the DAU_SPI_DIN line is checked against zero. If it is zero, the daughter board has been granted ownership. Direct communications with the SPI device can then proceed, by taking the DAU_SPI_MODE and DAU_SPI_SEL lines Low. The following software routine illustrates opening up an SPI channel for communications with a target SPI device: bool nanoboard_spi_open(unsigned int base, unsigned char device) { device |= 0x80; spi_control_write spi_divider_write spi_mode_hi //Enable bus request bit in address register (base,SPI_CTRL_ENABLE); (base,spi_divisor()); (base); //Access SPI address register

spi_send_wait_receive(base,0x80 | device); if (spi_send_wait_receive(base,0x80 | device) == 0) { spi_mode_lo spi_cs_lo return true; } else { return false; } } In the embedded software, the call to this routine could be in the form of a while loop, whereby the routine would be repeated (request bit set, target address loaded) until it returns True, meaning that Altium Designer or the firmware have released the SPI bus. For example: . . . while (!nanoboard_spi_open(Base_SPI, Device_Address)); . . . (base); (base);

AP0163 (v2.0) May 15, 2008

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01 Figures 5 and 6 illustrate wave diagrams to show the difference between a failed bus ownership request and a successful request, when trying to open communications with the Touch Screen Digitizer. In the latter case, once the daughter board FPGA has been given control of the SPI bus, the DAU_SPI_MODE and DAU_SPI_SEL lines are taken Low, switching access mode to direct bus communications and enabling the addressed device's chip select line. Communications with that device can then proceed, in accordance with the SPI bus data exchange protocol.

DAU_SPI_CLK

DAU_SPI_DOUT

DAU_SPI_DIN

DAU_SPI_MODE

DAU_SPI_SEL

Figure 5. Failed request to own the bus. The DAU_SPI_DIN line is still High after writing to the SPI address register, meaning the bus is not available.

DAU_SPI_CLK

DAU_SPI_DOUT

DAU_SPI_DIN

DAU_SPI_MODE

DAU_SPI_SEL

Figure 6. Successful request to own the bus. The DAU_SPI_DIN line is Low after writing to the SPI address register, meaning the bus is available. The DAU_SPI_MODE and DAU_SPI_SEL lines are then taken Low, to enable communications with the addressed device.

AP0163 (v2.0) May 15, 2008

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01

Selecting a Slave SPI Device for Communications

SPI on the NB2DSK01 is very much a multiple master, multiple slave environment. To reduce complexity, the SPI Controller provides multiplexed access to the external slave SPI devices. For all slave devices, the SCLK and DIN lines are common. For the majority of SPI devices, and specifically those which can be accessed from a design running on a daughter board FPGA device, the DOUT lines are also common. For these devices, the multiplexing process simply becomes a job of toggling the required chip select line for the device you wish to communicate with. The state of the individual chip select lines for the external SPI devices is controlled using the SEL and ADDR[4..0] lines. The SEL line is simply the DAU_SPI_SEL line routed through from the daughter board FPGA once ownership of the SPI bus has been granted. The ADDR[4..0] bus carries the address of the required device, and is the address loaded into bits 4..0 of the SPI Controller's internal 8-bit address register. Only one target SPI device can be selected for communications at any one time. The corresponding chip select line is taken Low (enabling communication with the device) provided that: The DAU_SPI_SEL line from the daughter board FPGA is taken Low and The address of the target device is apparent on the ADDR[4..0] line.

For devices that can be accessed from a daughter board FPGA design, the unique device addresses and associated chip select signals are summarized in Table 1.
Table 1. SPI device addresses and chip select signals.

Target Device Flash Memory (Embedded/FPGA Boot) Flash Memory (Embedded) Board Clock Touch Screen Digitizer Real Time Clock (RTC) Peripheral Board A (Device 1) Peripheral Board A (Device 2) Peripheral Board B (Device 1) Peripheral Board B (Device 2) Peripheral Board C (Device 1) Peripheral Board C (Device 2)

Address (Binary) 00001

Address (Hexadecimal) 0x01

Associated Chip Select Signal FLASH1_CS_N

00010 00100 00101 00110 00111 01000 01001 01010 01011 01100

0x02 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C

FLASH2_CS_N CLKGEN_CS_N TFT_SPI_CS_N RTC_CS_N EXTSPI_CSA_N0 EXTSPI_CSA_N1 EXTSPI_CSB_N0 EXTSPI_CSB_N1 EXTSPI_CSC_N0 EXTSPI_CSC_N1

Releasing the SPI Bus

Once you have finished communications with the intended slave SPI device, you must release the SPI bus. This is achieved by taking the DAU_SPI_MODE line High, switching from direct SPI bus access to access of the SPI Controller's internal address register. Once accessed, you need to flush the register writing it with all zeroes. As bit 7 of the register is no longer set, request of the SPI bus is cancelled and the SPI Controller will place the SPI bus back into the 'idle' (no ownership) state. In addition, you should also take the DAU_SPI_SEL line High. The following code routine shows how the release process can be implemented: void nanoboard_spi_close(unsigned int base) { spi_mode_hi (base );

spi_send_wait_receive(base,0); spi_cs_hi } (base );

AP0163 (v2.0) May 15, 2008

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01

Interface Wiring in the FPGA Design

Accessing an SPI-compatible resource from within an FPGA design is most easily accomplished by placing and wiring a Serial Peripheral Interface Controller device (SPI_W) and an SPI-based port component, which represents the pins of the physical FPGA device. Of course, you may be using your own HDL-based controller or, if feeling brave, attempt bit-banging direct from the processor in your design. The SPI_W however provides a simple and efficient interface solution. This Wishbone-compliant device offers full duplex communications and a serial clock that is configurable for polarity, phase and frequency. It is readily available for placement within your design: From a schematic document, the SPI_W device can be found in the FPGA Peripherals integrated library (FPGA Peripherals.IntLib), located in the \Library\Fpga folder of the installation. From an OpenBus System document, the SPI component can be found in the Peripherals region of the OpenBus Palette panel. A word addressing variant is also provided. For more information on the SPI_W peripheral, refer to the document CR0153 SPI_W Serial Peripheral Interface Controller. Several SPI-based port components exist for use in a design. Each port component interfaces to the same set of physical device pins, the only difference is in the associated graphic of the component used to better reflect the target device being communicated with. Table 2 summarizes the available SPI-based port components, including the library in which they can be found. Note that only one such component may be used in a design. If you wish to communicate with multiple SPI resources from your design (though not concurrently), a generic port component is available (see the following section).
Table 2. Resource-specific SPI-based port components.

Component Symbol

Component Name SERIALFMEMORY

Placed from... FPGA NB2DSK01 Port-Plugin integrated library (FPGA NB2DSK01 PortPlugin.IntLib), located in the \Library\Fpga folder of the installation.

TOUCH_SCREEN_DIGITIZER

AUDIO_CODEC_CTRL

FPGA PB01 Port-Plugin integrated library (FPGA PB01 Port-Plugin.IntLib), located in the \Library\Fpga folder of the installation.

Figure 7 illustrates an example of interfacing to the NB2DSK01 motherboard's SPI bus from a schematic-based design that uses a 32-bit processor in this case a TSK3000A. In this example, the design is using one of the SPI Flash memory devices as embedded memory, therefore the SERIALFMEMORY port component has been used to make this use of the SPI bus clearer. A configurable Wishbone Interconnect device (WB_INTERCON) is used to simplify connection and also handle the address mapping taking the 24-bit address line from the processor and mapping it to the 2-bit address line used to drive the intermediate SPI Controller device (SPI_W).

AP0163 (v2.0) May 15, 2008

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01

Figure 7. Accessing the SPI Flash memory from an FPGA design.

Communicating with Multiple SPI Devices

When interfacing to a single SPI device from an FPGA design, access to the device is straightforward simply place the specific port component representing the interface to that device, and wire to it (typically from an interface controller in the design). If your design is to communicate with multiple SPI devices, you can not simply place the corresponding specific port component for each device. To do so would result in multiple port components with the same pin names being used. This duplication of names will lead to errors when the design is processed for the target FPGA device. The solution is to place, and wire to, a single SPI-based port component. To use a specific port component can make the design hard to read, especially if the device represented graphically by the component is not even targeted by that design! To avoid this situation, a generic SPI-based port component is provided. Table 3 summarizes this component, which can be placed from the FPGA NB2DSK01 Port-Plugin.IntLib. Note: Your design may need to communicate with multiple SPI-based resources, but remember that communications can only be carried out with one such resource at a time. Access to each device, in turn, would be achieved through the embedded software for your design.
Table 3. Generic SPI port component.

Component Symbol

Component Name SPI_BUS

Description Place this component to include a generic interface to the NB2DSK01 motherboard's SPI bus within your FPGA design.

AP0163 (v2.0) May 15, 2008

Legacy documentation refer to the Altium Wiki for current information

SPI Communications on the Desktop NanoBoard NB2DSK01

Example Code
Example software routines used for opening and closing the NanoBoard SPI channel can be found in the following files: llpi_nb_spi.h llpi_nb_spi.c

Example software routines used in communicating with the SPI_W Controller can be found in the following files: llpi_wb_spi.h llpi_wb_spi.c

These files can be found in the \System\Tasking\dsf\llpi\include and \System\Tasking\dsf\llpi\src folders of the Altium Designer installation respectively.

Revision History
Date 27-Nov-2007 15-May-2008 Version No. 1.0 2.0 Revision Initial release Updated for Altium Designer Summer 08.

Software, hardware, documentation and related materials: Copyright 2008 Altium Limited. All Rights Reserved. The material provided with this notice is subject to various forms of national and international intellectual property protection, including but not limited to copyright protection. You have been granted a non-exclusive license to use such material for the purposes stated in the end-user license agreement governing its use. In no event shall you reverse engineer, decompile, duplicate, distribute, create derivative works from or in any way exploit the material licensed to you except as expressly permitted by the governing agreement. Failure to abide by such restrictions may result in severe civil and criminal penalties, including but not limited to fines and imprisonment. Provided, however, that you are permitted to make one archival copy of said materials for back up purposes only, which archival copy may be accessed and used only in the event that the original copy of the materials is inoperable. Altium, Altium Designer, Board Insight, DXP, Innovation Station, LiveDesign, NanoBoard, NanoTalk, OpenBus, P-CAD, SimCode, Situs, TASKING, and Topological Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. v8.0 31/3/08.

AP0163 (v2.0) May 15, 2008