WB_BOOTLOADER Configurable Flash SPI Bootloader

WB_BOOTLOADER Configurable Flash SPI Bootloader

Summary Core Reference CR0185 (v1.0) December 10, 2007

This document provides detailed reference information with respect to the WB_BOOTLOADER peripheral device. This device is primarily used to boot code resident in serial Flash memory on the NB2DSK01 motherboard, over to SRAM on the daughter board. It can also function as an SPI Controller.

The WB_BOOTLOADER peripheral provides the ability to automatically load (or bootstrap) from serial Flash memory on the Desktop NanoBoard NB2DSK01. The device provides the interface between the NB2DSK01'S SPI bus and independent SRAM on the daughter board. Provided the device is enabled for boot operation, then as soon as the design is programmed into the daughter board FPGA (or an external reset is issued if already programmed) the content of the serial Flash memory device will be copied into the SRAM.

The device is configurable in that you can specify where in SRAM the content copied from the serial Flash memory is to be written, and the size of the memory involved in the copy.

The WB_BOOTLOADER can also be used as a standard SPI Controller, with an optional interface to a processor in your design, enabling the processor to communicate with slave SPI-compatible devices external to the FPGA in which the design is running. Operating as an SPI Controller, the device is functionally identical to the SPI_W peripheral. Note: Although both M25P80 serial Flash memory devices on the NB2DSK01 can be used for embedded storage purposes, the WB_BOOTLOADER is hard-coded to boot from the device that is solely used for embedded purposes (designated U22 on the motherboard).

You must ensure that the required embedded code has been loaded into the serial Flash memory. This can be performed manually from the Instrument Rack – NanoBoard Controllers panel.

For more information on the programming procedure, refer to the document AP0162 Utilizing the SPI Flash Memory on the Desktop NanoBoard NB2DSK01.

Alternatively, you can download a design directly from an SD card inserted into the NB2DSK01 motherboard's SD card reader, through use of an EXAMPLE file (*.example). The programming file referenced in this file will be downloaded to the FPGA on the daughter board, and the referenced HEX file will be programmed into the serial Flash memory device, U22.

You could take this process a step further by setting the NB2DSK01 to automatically boot using an EXAMPLE file stored on an inserted SD card, on power-up.

For more information on EXAMPLE files and downloading/booting from an SD card, refer to the document AP0156 Interacting with the Desktop NanoBoard NB2DSK01.

CR0185 (v1.0) December 10, 2007 1


For detailed information on the Desktop NanoBoard NB2DSK01, refer to the document TR0143 Technical Reference Manual for Altium's Desktop NanoBoard NB2DSK01.

For detailed information on the Desktop NanoBoard's SPI communications system, refer to the document AP0163 SPI Communications on the Desktop NanoBoard NB2DSK01.

For more information on the SPI_W peripheral device, refer to the document CR0153 SPI_W Serial Peripheral Interface Controller.

Features • Bootloading functionality – copy code from serial Flash memory on the NB2DSK01 motherboard

into SRAM on the daughter board

• Configurable from the Schematic sheet or OpenBus System document

- Specify start address in SRAM at which to write content copied from serial Flash

- Specify the size of memory to be copied

• Optional use as SPI Controller peripheral (identical to SPI_W)

- Full duplex

- Serial clock signal configurable for polarity, phase and frequency

• Ability to bypass bootloading functionality and operate solely as an SPI Controller

• Wishbone-compliant

Available Devices From a schematic document, the WB_BOOTLOADER device can be found in the FPGA Peripherals integrated library (\Program Files\Altium Designer 6\Library\Fpga\FPGA Peripherals.IntLib).

From an OpenBus System document, the SPI Bootloader component can be found in the Peripherals region of the OpenBus Palette panel.

2 CR0185 (v1.0) December 10, 2007


Functional Description

Symbol

Figure 1. Symbols used for the SPI Bootloader in both schematic (left) and OpenBus System (right).

Figure 1 illustrates an example of the SPI Bootloader's schematic and OpenBus symbols, when configured to have the slave SPI Controller interface, for processor application.

Pin description The following pin description is for the device when used on the schematic. In an OpenBus System, although the same signals are present, the abstract nature of the system hides the pin-level Wishbone interfaces. The external interface signals to the SPI bus will be made available as sheet entries, associated with the parent sheet symbol used to reference the underlying OpenBus System.

CR0185 (v1.0) December 10, 2007 3


Table 1. WB_BOOTLOADER pin description

Name Type Polarity/Bus size

Description

Control Signals

CLK I Rise External (system) clock signal

RST I High External (system) reset

ENABLE I High Enable signal. Typically tie this input High (to VCC) to enable bootloading functionality

CPU_HOLD O High CPU Hold signal. This signal should be connected to the processor's RST_I input and provides a separate reset signal to the processor and its connected I/O peripheral devices. All memory devices in the system are still reset using the standard RST signal.

This signal ensures that the processor and its I/O slaves are not reset until after the WB_BOOTLOADER has finished copying from the serial Flash memory to the SRAM.

This signal will be taken High if the bootloading process is not yet finished, OR if an external reset is received on the device's RST input.

Host Processor Interface Signals

io_STB_I I High Strobe signal. When asserted, indicates the start of a valid Wishbone data transfer cycle

io_CYC_I I High Cycle signal. When asserted, indicates the start of a valid Wishbone cycle

io_ACK_O O High Standard Wishbone device acknowledgement signal. When this signal goes high, the WB_BOOTLOADER (Wishbone Slave) has finished execution of the requested action and the current bus cycle is terminated

io_ADR_I I 2 Address bus, used to select an internal register of the device for writing to/reading from

io_DAT_O O 8 Data to be sent to host processor

io_DAT_I I 8 Data received from host processor

io_WE_I I Level Write enable signal. Used to indicate whether the current local bus cycle is a Read or Write cycle:

0 = Read

1 = Write

4 CR0185 (v1.0) December 10, 2007



Description

io_CLK_I I Rise External (system) clock signal. This signal is identical to the CLK_I input of the processor, and is simply the clock line output as part of the processor's External Peripheral I/O interface.

io_RST_I I High External reset signal. This signal is identical to the RST_I input of the processor, and is simply the reset line output as part of the processor's External Peripheral I/O interface.

io_INT_O O High Interrupt output line. This signal is currently not supported and is grounded internally

SRAM Interface Signals

me_STB_O O High Strobe signal. When asserted, indicates the start of a valid Wishbone data transfer cycle

me_CYC_O O High Cycle signal. When asserted, indicates the start of a valid Wishbone cycle. This signal remains asserted until the end of the bus cycle, where such a cycle can include multiple data transfers

me_ACK_I I High Standard Wishbone device acknowledgement signal. When this signal goes high, the connected Wishbone memory device has finished execution of the requested action and the current bus cycle is terminated

me_ADR_O O 20 Standard Wishbone address bus, used to select an address of the connected Wishbone memory for writing to/reading from

me_DAT_I I 32 Data received from external Wishbone memory

me_DAT_O O 32 Data to be sent to external Wishbone memory

me_SEL_O O 4/High Select output, used to determine where data is placed on the me_DAT_O line during a Write cycle, and from where on the me_DAT_I line data is accessed during a Read cycle. For the WB_BOOTLOADER, only 32-bit data transfers to/from Wishbone memory are supported, meaning that all the lines go High during a Write or Read cycle

me_WE_O O Level Write enable signal. Used to indicate whether the current local bus cycle is a Read or Write cycle:

0 = Read

1 = Write

CR0185 (v1.0) December 10, 2007 5



Description

me_CLK_O O Rise External (system) clock signal (identical to CLK), made available for connecting to the CLK_I input of a slave memory device. Though not part of the standard Wishbone interface, this signal is provided for convenience when wiring your design

me_RST_O O High Reset signal made available for connection to the RST_I input of a slave memory device. This signal goes High when an external reset is issued to the WB_BOOTLOADER on its RST pin. Though not part of the standard Wishbone interface, this signal is provided for convenience when wiring your design

SPI Bus Interface Signals

SPI_DOUT O - Serial Data Out. This is the data written to the target SPI-compatible slave device. Data is shifted into the slave device on the rising edge of the serial clock.

SPI_DIN I - Serial Data In. This is the data read from the target SPI-compatible slave device. Data is shifted out of the slave device on the falling edge of the serial clock

SPI_CLK O - Serial Clock. This signal is generated by the WB_BOOTLOADER and is used to clock data in and out of the slave SPI device.

SPI_MODE O Level Access Mode (when communicating with SPI resources within the Desktop NanoBoard system). When using the WB_BOOTLOADER as a standard SPI Controller, the level of this signal determines whether the FPGA design accesses the NB2DSK01's SPI Controller, or the SPI bus directly: • High – communicate with the SPI Controller and, more

specifically, an 8-bit SPI device address register therein. • Low – communicate directly with a slave device over the SPI

bus. This output follows the level of the mode bit in the Control/Status register (CSR.2)

SPI_CS O Level Serial Chip Select. When using the WB_BOOTLOADER as a standard SPI Controller, take this signal Low to enable a connected SPI slave device for communications. This output follows the level of the cs bit in the Control/Status register (CSR.1)

Note: For detailed information on the SPI communications system in place on the NB2DSK01, and how the SPI_MODE and SPI_CS lines are used, refer to the document AP0163 SPI Communications on the Desktop NanoBoard NB2DSK01.

6 CR0185 (v1.0) December 10, 2007


Hardware Description

Block Diagram

SPI Bootloader

SPI Clock Generation Unit

CDIV

Internal Counter

DATAOUT

DATAIN

CSR

Internal ShiftRegister

Internal StateMachine(FSM)

MEM_START

MEM_CURRENT

MEM_SIZE

WORD_COUNT

io_STB_Iio_CYC_Iio_ACK_Oio_ADR_I[1..0]io_DAT_O[7..0]io_DAT_I[7..0]io_WE_Iio_CLK_Iio_RST_Iio_INT_O

CLKRSTENABLECPU_HOLD

me_STB_Ome_CYC_Ome_ACK_Ime_ADR_O[19..0]me_DAT_OI31..0]me_DAT_O[31..0]

me_WE_Ome_CLK_Ome_RST_O

me_SEL_O[3..0]

SPI_CLK

SPI_DOUTSPI_DIN

SPI_MODESPI_CS

CSR.2

CSR.1

Figure 2. WB_BOOTLOADER block diagram.

Internal Registers The SPI Bootloader device contains four internal registers that are accessible by software, when the optional SPI Controller port is enabled – CSR, CDIV, DATAOUT, DATAIN. These registers allow the device to be used as an SPI Controller for communications between the processor in the design and external slave SPI devices.

Two additional registers – MEM_START, MEM_SIZE – relate to the bootloading functionality of the device. These registers are not accessible directly from the software. The values to these registers are written indirectly, through the associated configuration dialog for the device.

The following sections detail each of these registers.

CR0185 (v1.0) December 10, 2007 7


Control/Status register (CSR) Address: 01

Access: Read and Write

Value after Reset: 00h

This 8-bit register is used to control aspects of the SPI Bootloader's operation, when used as an SPI Controller, and to determine the current state of the Controller.

Table 2. The CSR register

MSB LSB

7 6 5 4 3 2 1 0

busy - - cpha cpol mode cs txen

Table 3. The CSR register bit functions

Bit Symbol Function

CSR.7 busy Controller Busy status flag. This bit is set High whenever the Controller has started transmitting data to the target SPI peripheral device (i.e. FSM has left the IDLE state)

CSR.6 - Not used

CSR.5 - Not used

CSR.4 cpha SPI Clock Phase control bit. Determines the phase of the SPI_CLK signal, in relation to the transmitted data on the SPI_DOUT line:

0 – the first edge of the SPI_CLK signal is generated half an SPI_CLK period after the MSB of the data to be transmitted is made available on the SPI_DOUT line. Data will be latched on the leading edge and changed on the trailing edge

1 – the first edge of the SPI_CLK signal is generated in conjunction with the MSB of the data to be transmitted being made available on the SPI_DOUT line. Data will be changed on the leading edge and latched on the trailing edge

CSR.3 cpol SPI Clock Polarity control bit. Determines the idle (inactive) state for the SPI_CLK signal:

0 – SPI_CLK signal is inactive Low

1 – SPI_CLK signal is inactive High

CSR.2 mode SPI_MODE control bit. This bit is directly linked to the Controller's SPI_MODE output pin and can be used to control this signal as required

CSR.1 cs SPI_CS control bit. This bit is directly linked to the Controller's SPI_CS output pin and can be used to control this signal as required. When this signal is

8 CR0185 (v1.0) December 10, 2007


Bit Symbol Function

connected to the corresponding chip select input of a peripheral SPI device, taking the signal Low will enable that device for serial communications with the Controller. When the target SPI device is not selected (i.e. CSR.1 is '1'), it must tristate its data output

CSR.0 txen Transfer Enable control bit. Used to control state machine operation:

0 – Initiate serial communications transfer

1 – Inhibit serial communications

Note: Bits 6 and 5 are ignored when writing to the register and return '0' when read. Bit 7 is Read-only.

Clock Divider register (CDIV) Address: 10

Access: Read and Write


This 8-bit register is used to store a divisor for use in generation of the SPI_CLK signal, based on the external clock signal (io_CLK_I). As part of the SPI Clock Generation Unit, an internal counter is used to count up to the value written to the CDIV register. The next edge of SPI_CLK will only be generated when the internal counter reaches this divisor value.

The value written to the Clock Divider register can be anywhere in the valid range 0 to 28 – 1.

Table 4. The CDIV register

MSB LSB

7 6 5 4 3 2 1 0

div7 div6 div5 div4 div3 div2 div1 div0

Table 5. The CDIV register bit functions

Bit Symbol Function

CDIV.7 div7 Clock Divisor bit 7








CR0185 (v1.0) December 10, 2007 9


Parallel-to-Serial Data register (DATAOUT) Address: 00

Access: Write-only


This 8-bit register is used to store the data to be transmitted to the target slave SPI device.

The value written to this register can be anywhere in the valid range 0 to 28 – 1.

Table 6. The DATAOUT register

MSB LSB

7 6 5 4 3 2 1 0

data7 data6 data5 data4 data3 data2 data1 data0

Table 7. The DATAOUT register bit functions

Bit Symbol Function

DATAOUT.7 data7 Transmit data bit 7








Serial-to-Parallel Data register (DATAIN) Address: 00

Access: Read-only


This 8-bit register is used to store the data received from the target slave SPI device.

The value in this register can be anywhere in the valid range 0 to 28 – 1.

Table 8. The DATAIN register

MSB LSB

7 6 5 4 3 2 1 0

data7 data6 data5 data4 data3 data2 data1 data0

10 CR0185 (v1.0) December 10, 2007


Table 9. The DATAIN register bit functions

Bit Symbol Function

DATAIN.7 data7 Received data bit 7








Memory Start Address register (MEM_START) This register is used to hold the value for the starting address in SRAM, from where the code copied from the serial Flash memory will be written, during the bootloading process. This value is specified as part of the SPI Bootloader device's configuration, using the Bootloader System Configuration dialog (see section Configuring the SPI Bootloader device).

An additional internal register, MEM_CURRENT, is used to hold the current (SRAM) address that is being written to. After a reset, the MEM_CURRENT register will be loaded with the value stored in the MEM_START register. The actual address sent out on the me_ADR_O line to the physical SRAM device is:

me_ADR_O[19..0] = MEM_CURRENT[17..0] & "00"

Memory Size register (MEM_SIZE) This register is used to hold the value, in bytes, for the size of memory to be copied from the serial Flash memory to the SRAM, during the bootloading process. This value is specified as part of the SPI Bootloader device's configuration, using the Bootloader System Configuration dialog (see section Configuring the SPI Bootloader device).

An additional internal register, WORD_COUNT, is used to hold the value for the remaining number of words to be copied from serial Flash memory. After a reset, the WORD_COUNT register will be loaded with the value stored in the MEM_SIZE register.

CR0185 (v1.0) December 10, 2007 11


Wiring an SPI Bootloader device into a design How the SPI Bootloader device is placed and wired within an FPGA design depends on two things:

• How the device is being used – for bootloading and SPI control, for bootloading purposes only, or purely as an SPI Controller.

• The method used to build the design. The main processor-based system can be defined purely on the schematic sheet, or it can be contained as a separate OpenBus System, which is then referenced from the top-level schematic.

The following sections take a look at using the SPI Bootloader device in various situations.

Bootloading & SPI Control (Schematic-based) Figure 3 illustrates how a WB_BOOTLOADER device can be wired into a schematic-based design that uses a 32-bit processor – in this case a TSK3000A. The enabled SPI Controller interface is wired to the processor via a configurable Wishbone Interconnect device (WB_INTERCON). This device 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 WB_BOOTLOADER.

The WB_BOOTLOADER's memory interface is wired, through a Wishbone Multi-master device (WB_MULTIMASTER) and subsequent SRAM Controller (not shown), to the physical SRAM memory into which the booted code will be written. This memory is also accessible by the processor.

The WB_BOOTLOADER's SPI bus interface signals have been connected to the TOUCH_SCREEN_DIGITIZER port component, which represents the pins of the physical FPGA device.

Figure 3. Example interfacing between a 32-bit processor (TSK3000A) and a WB_BOOTLOADER.

12 CR0185 (v1.0) December 10, 2007


The bootloading functionality of the WB_BOOTLOADER is permanently enabled by having tied its ENABLE input to VCC. Notice that the external system reset signal, RST_I, is wired to the RST input of the device and also to the m0_RST_I input of the interconnect device, on the memory side of the processor. The processor itself however (and the connected I/O peripheral devices) are reset using the RST_PROC signal – sourced from the WB_BOOTLOADER'S CPU_HOLD output.

When configuring the WB_INTERCON device – in particular the WB_BOOTLOADER slave interface – ensure that the Address Bus Mode is set to Byte Addressing – ADR_O(0) <= ADR_I(0).

The Base Address for the WB_BOOTLOADER is specified as part of the peripheral’s definition when adding it as a slave to the Wishbone Interconnect. For example, if the base address entered for the device is 100000h (mapping it to address FF10_0000h in the processor’s address space), and you want to write to the Command/Status register (CSR) with binary address 01 (or 1h), the value entered on the processor’s IO_ADR_O line would be:

100000h + 1h = 100001h

For further information on the Wishbone Interconnect, refer to the CR0150 WB_INTERCON Configurable Wishbone Interconnect core reference.

For further information on the Wishbone Multi-master, refer to the CR0168 WB_MULTIMASTER Configurable Wishbone Multi-Master core reference.

For further information on the TSK3000A processor, refer to the CR0121 TSK3000A 32-bit RISC Processor core reference. Similar references can be found for other 32-bit processors supported by Altium Designer, by using the lower section of the Knowledge Center panel and navigating to the Documentation Library » Embedded Processors and Software Development » FPGA Based and Discrete Processors section.

For an example schematic-based FPGA design featuring a WB_BOOTLOADER device, used for bootloading and as an SPI Controller, refer to the example project: \Program Files\Altium Designer 6\Examples\NB2DSK1 Examples\DSF Ethernet Analyzer\DSF_Ethernet_Analyser.PrjFpg.

Bootloading & SPI Control (OpenBus System-based) Figure 4 illustrates use of the WB_BOOTLOADER peripheral within a design where the main processor system has been defined as an OpenBus System. The SPI Bootloader peripheral (as it is referred to in the OpenBus System world) is connected to the TSK3000A processor through an Interconnect component.

The OpenBus System environment is a much more abstract and intuitive place to create a design, where the interfaces are reduced to single ports and connection is made courtesy of single links.

Much of the configuration is handled for you – there is no addressing mode to specify, no data width to enter – the SPI Bootloader peripheral is automatically added as a slave to the Interconnect component by virtue of its link. The Interconnect contains information regarding the device's address bus size and a default decoder address width. All that is really needed is specification of the peripheral's base address – where in the TSK3000A's address space it is to be mapped.

CR0185 (v1.0) December 10, 2007 13


Figure 4. Example interfacing between a 32-bit processor (TSK3000A) and an SPI Bootloader device, as part of an OpenBus System.

The SPI Bootloader's master port (its memory interface) is linked to an Arbiter component (ARBT_TFT)) and subsequent SRAM Controller (VIDEO_RAM). This memory is also accessible by the processor. An OpenBus System is defined on an OpenBus System Document (*.OpenBus). This document is referenced from the FPGA design's top-level schematic sheet through a sheet symbol. Figure 5 illustrates the interface circuitry between the SPI Bootloader's external interface and the physical pins of the target FPGA device – represented by the TOUCH_SCREEN_DIGITIZER port component.

14 CR0185 (v1.0) December 10, 2007


Figure 5. Wiring the OpenBus System-based SPI Bootloader to the physical pins of the FPGA device.

The bootloading functionality of the SPI Bootloader is permanently enabled by having tied the SPI_BOOT_ENABLE sheet entry input to VCC. The device's CPU_HOLD output, which appears as sheet entry SPI_BOOT_CPU_HOLD, is connected to the sheet entry RST_PROC, to provide the reset signal to the processor (and I/O peripherals) in the OpenBus System.

The external CLK and RST signals required as inputs to the device will also be defined on the top-level schematic, and 'fed' into the OpenBus System through corresponding sheet entries on the sheet symbol. Specification of the required reset lines is managed in the OpenBus Signal Manager dialog (Tools » OpenBus Signal Manager). Figure 6 illustrates this dialog for the OpenBus design in Figure 4.

Figure 6. Specifying the reset lines for devices in the OpenBus System.

Notice that as there are no reset lines associated with Interconnect devices in an OpenBus System, the memory path relating to the EMAC peripheral (including the ARB_EMAC and EMAC_RAM devices) are set to have the RST_PROC signal, the same as for the processor itself. The standard external reset line is only needed for the devices in the path which includes the SPI Bootloader.

For further information on the Interconnect component, refer to the document TR0170 OpenBus Interconnect Component Reference.

For further information on the Arbiter component, refer to the document TR0171 OpenBus Arbiter Component Reference.

CR0185 (v1.0) December 10, 2007 15


For more information on the concepts and workings of the OpenBus System, refer to the article AR0144 Streamlining Processor-based FPGA design with the OpenBus System.

For an example OpenBus System-based FPGA design featuring an SPI Bootloader device, used for bootloading and as an SPI Controller, refer to the example project: \Program Files\Altium Designer 6\Examples\NB2DSK1 Examples\OpenBus DSF Ethernet Analyzer\DSF_Ethernet_Analyser.PrjFpg.

16 CR0185 (v1.0) December 10, 2007


Bootloading only (Schematic-based) Figure 7 illustrates a schematic-based design where a WB_BOOTLOADER device is being used for bootloading purposes only.

In this case, there is no SPI Controller interface and the device's memory interface is simply wired directly, through a Wishbone Multi-master device and subsequent SRAM Controller, to the physical SRAM memory into which the booted code will be written, and which is also accessible by the processor in the design.

The WB_BOOTLOADER's SPI bus interface signals have been connected to the SPI_BUS port component, which represents the pins of the physical FPGA device.

Figure 7. Example of using a WB_BOOTLOADER device solely for booting from serial Flash memory.

The bootloading functionality of the WB_BOOTLOADER is permanently enabled by having tied its ENABLE input to VCC. Notice that the external system reset signal, RST, is wired to the RST input of the device and also to the m0_RST_I input of the interconnect device, on the memory side of the processor. The processor however (and the connected I/O peripheral devices) are reset using the RST_CPU signal – sourced from the WB_BOOTLOADER'S CPU_HOLD output.

For an example schematic-based FPGA design featuring a WB_BOOTLOADER device, used for bootloading purposes only, refer to the example project: \Program Files\Altium Designer 6\Examples\NB2DSK1 Examples\DSF Infrared RC\DSF_Infrared_RC.PrjFpg.

CR0185 (v1.0) December 10, 2007 17


Bootloading only (OpenBus System-based) Figure 8 illustrates an OpenBus System where an SPI Bootloader component is being used for bootloading purposes only.

As the device is not being used for SPI control, it has just a master port, representing the memory interface. This port is linked directly to the Arbiter component to which the physical SRAM (via appropriately configured SRAM Controller) is connected. This SRAM is accessible by both the SPI Bootloader and the processor.

Figure 9 illustrates the interface circuitry between the SPI Bootloader's external interface and the physical pins of the target FPGA device – represented by the SPI_BUS port component.

The bootloading functionality of the SPI Bootloader is permanently enabled by having tied the SPI_BOOT_ENABLE sheet entry input to VCC. The device's CPU_HOLD output, which appears as sheet entry SPI_BOOT_CPU_HOLD, is connected to the sheet entry RST_PROC, to provide the reset signal to the processor (and I/O peripherals) in the OpenBus System.

Figure 8. Using an SPI Bootloader device for bootloading purposes only, as part of an OpenBus System.

Figure 9. Wiring the OpenBus System-based SPI Bootloader to the physical pins of the FPGA device.

Again, definition of the reset lines is performed in the OpenBus Signal Manager dialog and, in this case, would involve setting the reset lines for the Arbiter and SRAM components to RST_I and all other device reset lines to RST_PROC.

For an example OpenBus System-based FPGA design featuring an SPI Bootloader component, used for bootloading purposes only, refer to the example project: \Program Files\Altium Designer 6\Examples\NB2DSK1 Examples\OpenBus Infrared RC\DSF_Infrared_RC.PrjFpg.

18 CR0185 (v1.0) December 10, 2007


SPI Control only Should you wish, you can disable the bootloading functionality of the SPI Bootloader device, using it as standard SPI Controller. This is achieved by four very simple steps: • Tie the ENABLE pin of the device Low (to GND)

• Place a No ERC directive on the CPU_HOLD output

• Terminate the unused memory interface: - Schematic – connect me_ACK_I to VCC, me_DAT_I to GND and place No ERC directives on

each of the remaining pins of the memory interface - OpenBus System – place and link a Port Terminator component to the device's memory

(master) port

• Ensure that all devices in the system are reset using the standard, external system reset line (typically labeled RST_I).

Figure 10. Disabling bootloading functionality and using the SPI Bootloader purely as an SPI Controller (Schematic-based system).

CR0185 (v1.0) December 10, 2007 19


Figure 11. Disabling bootloading functionality and using the SPI Bootloader purely as an SPI Controller (OpenBus System).

20 CR0185 (v1.0) December 10, 2007


Configuring the SPI Bootloader device The SPI Bootloader device can be configured after placement on the schematic sheet, or OpenBus System document, using the Bootloader System Configuration dialog (Figure 12). Access to this dialog depends on the document in which you are working: • In the Schematic document – simply right-click over the device and choose the Configure

command from the context menu that appears. Alternatively, click on the Configure button, available in the Component Properties dialog for the device.

• In the OpenBus System document – access the dialog by right-clicking over the component and choosing the Configure command from the menu that appears. Alternatively, double-click on the component to access the dialog directly.

Figure 12. Configuring the SPI Bootloader peripheral.

Use the dialog to define the following properties for the device as required:

Start Address Use this field to define the starting address in SRAM, from where the code copied from the serial Flash memory should be written, during the bootloading process. The value will be stored in a dedicated register and copied to an internal working register after a reset and prior to the boot process initiating. See the section Memory Start Address register (MEM_START), earlier in this document, for more information.

Size Use this field to define the value, in bytes, for the size of memory to be copied from the serial Flash memory to the SRAM, during the bootloading process. The value will be stored in a dedicated register and copied to an internal working register after a reset and prior to the boot process initiating. See the section Memory Size register (MEM_SIZE), earlier in this document, for more information. Note: The size can be specified as a decimal or hex value (e.g. 256k, 0x18000)

CR0185 (v1.0) December 10, 2007 21


Slave SPI Controller Port Enable this option if you want to make use of the device as an SPI Controller. A slave peripheral interface will be added to the device, for connection to a processor in the design.

If you are purely using the device for its bootloading functionality, leave this option disabled.

Master Address Width (Schematic-based design only) Use this field to define the width of the address bus in the device's memory interface.

Extra Space (Schematic-based design only) When the additional slave interface is enabled, for SPI Controller functionality, that interface will appear above the memory interface. Use this field to determine the amount of blank space between the two interfaces, on the schematic symbol.

22 CR0185 (v1.0) December 10, 2007


Host to Controller Communications When enabled for operation as an SPI Controller, communications between a 32-bit host processor and the SPI Bootloader device are carried out over a standard Wishbone bus interface. The following sections detail the communication cycles involved between host and peripheral device for writing to/reading from the internal registers.

Writing to an Internal Register Data is written from the host processor to an internal register in the SPI Bootloader, in accordance with the standard Wishbone data transfer handshaking protocol. The write operation occurs on the rising edge of the CLK_I signal and can be summarized as follows:

• The host presents the required 24-bit address based on the register to be written on its IO_ADR_O output and valid data on its IO_DAT_O output. It then asserts its IO_WE_O signal, to specify a write cycle

• The SPI Bootloader receives the 2-bit address on its io_ADR_I input and, identifying the addressed register, prepares to receive data into that register

• The host asserts its IO_STB_O and IO_CYC_O outputs, indicating that the transfer is to begin. The SPI Bootloader, which monitors its io_STB_I and io_CYC_I inputs on each rising edge of the CLK_I signal, reacts to this assertion by latching the data appearing at its io_DAT_I input into the target register and asserting its io_ACK_O signal – to indicate to the host that the data has been received

• The host, which monitors its IO_ACK_I input on each rising edge of the CLK_I signal, responds by negating the IO_STB_O and IO_CYC_O signals. At the same time, the SPI Bootloader negates the io_ACK_O signal and the data transfer cycle is naturally terminated.

Table 10 summarizes how the data from the host processor is used by each of the internal registers.

Table 10. Values written to internal registers during a write.

Writing to... Results in...

DATAOUT io_DAT_I(7..0) loaded into the Parallel-to-Serial Data register

CSR io_DAT_I(4..0) loaded into the Control/Status register

CDIV io_DAT_I(7..0) loaded into the Clock Divider register

Note: DATAOUT and DATAIN registers use the same address ("00"). Provided you are performing a write (io_WE_I input High), you will access the DATAOUT register.

CR0185 (v1.0) December 10, 2007 23


Reading from an Internal Register Data is read from an internal register in accordance with the standard Wishbone data transfer handshaking protocol. The read operation, which occurs on the rising edge of the CLK_I signal, can be summarized as follows:

• The host presents the required 24-bit address based on the register to be read on its IO_ADR_O output. It then negates its IO_WE_O signal, to specify a read cycle

• The SPI Bootloader receives the 2-bit address on its io_ADR_I input and, identifying the addressed register, prepares to transmit data from the selected register

• The host asserts its IO_STB_O and IO_CYC_O outputs, indicating that the transfer is to begin. The SPI Bootloader, which monitors its io_STB_I and io_CYC_I inputs on each rising edge of the CLK_I signal, reacts to this assertion by presenting the valid data on its io_DAT_O output and asserting its io_ACK_O signal – to indicate to the host that valid data is present

• The host, which monitors its IO_ACK_I input on each rising edge of the CLK_I signal, responds by latching the data appearing at its IO_DAT_I input and negating the IO_STB_O and IO_CYC_O signals. At the same time, the SPI Bootloader negates the io_ACK_O signal and the data transfer cycle is naturally terminated.

Table 11 summarizes the 'make-up' of the 32-bit data word that is read back from each register.

Table 11. Values read from internal registers during a read.

Reading from... Presents (to host processor)...

DATAIN "000000000000000000000000" & 8-bit value currently in the Serial-to-Parallel Data register

CSR "000000000000000000000000" & CSR.7 & "00" & CSR(4..0)

CDIV "000000000000000000000000" & 8-bit value currently in the Clock Divider register

Note: DATAOUT and DATAIN registers use the same address ("00"). Provided you are performing a read (io_WE_I input Low), you will access the DATAIN register.

24 CR0185 (v1.0) December 10, 2007


Operational Overview Provided the starting address in SRAM and the size of transfer are both specified in the configuration dialog for the SPI Bootloader, the bootloading functionality will be automatic upon FPGA design download or subsequent system reset. Transfer from the serial Flash memory will always be from address zero. Note: In the example designs earlier in this document, the bootloading functionality has always been enabled permanently, through tying the ENABLE input of the device High. For even more flexibility, you could wire this input to a switch, giving you the option to manually enable or disable the bootloading functionality, without having to modify and reprocess your design. On the NB2DSK01 for example, you could wire this input to the dipswitch, or one of the generic user switches.

The following steps outline the basic procedure in order to initiate serial communications with the target SPI peripheral device, when using the SPI Bootloader device as an SPI Controller.

Initialization After an external reset, you will need to initialize the SPI Bootloader. This should be carried out in accordance with design requirements and can include:

• Writing to the Control/Status register (CSR) and defining: - The phase and polarity of the SPI_CLK signal, using bits cpha (CSR.4) and cpol (CSR.3)

respectively - The level of the SPI_MODE signal output, using the mode bit (CSR.2)

- The level of the SPI_CS signal output, using the cs bit (CSR.1). By default, this bit will be cleared after a reset and therefore in the correct state for enabling the target SPI device.

- Transmission enable/inhibit, using the txen bit (CSR.0). By default, this bit will be cleared after a reset and therefore in the correct state to enable transmission upon reception of data in the Parallel-to-Serial Data register (DATAOUT). Should you wish to inhibit transmission, set this bit to '1'.

• Writing to the Clock Divider register (CDIV) with the required value for division of the CLK signal, to achieve the desired SPI_CLK frequency.

Transmission In order to start the Controller's internal state machine – and hence transmission of data to/reception of data from the target SPI device – simply write the data to be transmitted into the Parallel-to-Serial Data register (DATAOUT) and ensure that the txen bit in the Control/Status register is '0'.

The Controller's state machine will generate the serial clock (SPI_CLK) and manage the data flow as follows:

• The byte of data to be transmitted will be copied into an internal shift register.

• The MSB of this data will be shifted out onto the SPI_DOUT line (to the target SPI device). As the state machine is no longer in the IDLE state, the busy flag is set (High) in the Control/Status register (CSR.7), indicating that the Controller is transmitting

CR0185 (v1.0) December 10, 2007 25


• At the same time, a bit of data is received from the target SPI device on the Controller's SPI_DIN line and shifted into bit 0 of the internal shift register.

• An internal bit counter keeps track of the transmission, which proceeds until all 8 bits of the data to be transmitted have been sent. At this time, the internal shift register holds an 8-bit data value received from the SPI device.

• The valid byte of data is loaded from the internal shift register into the Serial-to-Parallel Data register (DATAIN), ready to be read by the host processor.

Revision History

Date Version No. Revision

10-Dec-2007 1.0 Initial release

Software, hardware, documentation and related materials:

Copyright © 2007 Altium Limited.

All rights reserved. You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, Altium Designer, Board Insight, Design Explorer, DXP, LiveDesign, NanoBoard, NanoTalk, 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.

26 CR0185 (v1.0) December 10, 2007

Documents

WB_BOOTLOADER Configurable Flash SPI Bootloader