WB_BOOTLOADER - Interfacing

How the SPI Bootloader component 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 contained as a separate OpenBus System, which is then referenced from the top-level schematic, or it can be defined purely on the schematic sheet.

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

Bootloading & SPI Control (OpenBus System-Based)

Figure 1 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 component'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.

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 2 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.

The bootloading functionality of the SPI Bootloader is permanently enabled by having tied the SPI_BOOT_ENABLE sheet entry input to VCC. The component'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 3 illustrates this dialog for the OpenBus design in Figure 1.

Notice that as there are no reset lines associated with Interconnect components 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 components in the path which includes the SPI Bootloader.

Bootloading & SPI Control (Schematic-Based)

Figure 4 illustrates how a WB_BOOTLOADER component 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 component (WB_INTERCON). This component 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 component (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.

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 component, 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 component – 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

Bootloading Only (OpenBus System-Based)

Figure 5 illustrates an OpenBus System where an SPI Bootloader component is being used for bootloading purposes only.

As the component 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 6 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 component's CPU_HOLD output, which appears as sheet entry SPI_BOOT_CPU_HOLD, is connected to the sheet entry RST_CPU, to provide the reset signal to the processor (and I/O peripherals) in the OpenBus System.

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_CPU.

Bootloading Only (Schematic-Based)

Figure 7 illustrates a schematic-based design where a WB_BOOTLOADER component 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 component 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.

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.

SPI Control Only

Should you wish, you can disable the bootloading functionality of the SPI Bootloader component, 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).

See Also