WB_SHARED_MEM_CTRL - Interfacing

Frozen Content
Modified by Admin on Sep 13, 2017

Physical memory is connected to a processor's External Memory interface. How the WB_SHARED_MEM_CTRL is placed and wired within an FPGA design to facilitate this, depends on the method used to build that 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 WB_SHARED_MEM_CTRL in both of these design arenas.

Design using a Schematic only

Figure 1 illustrates an example of how a WB_SHARED_MEM_CTRL component can be wired into a schematic-based design that uses a 32-bit processor – in this case a TSK3000A. In this example, the Controller is configured to interface to all three common-bus memories available on the 3-connector daughter board, which houses the physical FPGA device to which the design is targeted. We'll assume that the daughter board – plugged into the Desktop NanoBoard NB2DSK01 – is a Xilinx Spartan-3 (DB30). The three common-bus memories on this board are:

  • 256K x 32-bit SRAM (1MByte) – 2 x 16-bit devices
  • 16M x 32-bit SDRAM (64MByte) – 2 x 16-bit devices
  • 16M x 16-bit Flash memory (32MByte) – 1 x 16-bit device

On the processor side, the Controller's three separate memory interfaces are wired back to the processor's External Memory interface, using a WB_INTERCON device. This enables the processor to access all three memories over its single bus interface and handles the address line mapping.

On the physical memory side, the Controller's physical memory interface signals are connected to the SHARED_MEM_DAUGHTER port component, which represents the pins of the physical FPGA device.


Figure 1. Using a Shared Memory Controller to access common-bus memory on a daughter board.

Design Featuring an OpenBus System

Figure 2 illustrates identical use of the WB_SHARED_MEM_CTRL peripheral within a design where the main processor system has been defined as an OpenBus System. The Shared Memory Controller component (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.


Figure 2. Example interfacing between a 32-bit processor (TSK3000A) and
a Shared Memory Controller device, as part of an OpenBus System.

Much of the configuration is handled for you – there is no addressing mode to specify, no data width to enter – each of the separate memory interfaces for the Shared Memory Controller component is automatically added as a slave to the Interconnect component by virtue of its link. The Interconnect contains information regarding each interface's address bus size and a default decoder address width. All that is really needed is specification of the base address for each memory type – where in the TSK3000A's address space these memories are to be mapped.

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 3 illustrates the interface circuitry between the Shared Memory Controller's external interface and the physical pins of the target FPGA device – represented by the SHARED_MEM_DAUGHTER port component.


Figure 3. Wiring the OpenBus System-based Shared Memory Controller to the physical pins of the FPGA device.

Physical Interface to Memory

For 32-bit processors the physical interface to the outside world is always 32 bits wide. Since the addressing has a byte-level resolution, this means that up to four "packets" of data (bytes) can be loaded or stored during a single memory access. To accommodate this requirement all memory accesses (8-bit, 16-bit and 32-bit) are handled in a specific way.

Each 32-bit Read and Write can be considered as a Read or Write through four "byte-lanes". These byte-lanes are marked as valid by the corresponding bits in the ME_SEL_0[3..0] signal of the processor's External Memory interface. Each bit will be High if the byte data in that lane is valid. This allows a single byte to be written to 32-bit wide memory without needing to use a slower read-modify-write cycle.

The instructions of the processor require that all 32-bit load/store operations be aligned on 4-byte boundaries and all 16-bit load/store operations be aligned on 2-byte boundaries. Byte operations (8-bit) can be to any address.

To complete a byte load or store, the processor will position the byte data in the correct byte-lane and set the ME_SEL_O signal for that lane High. The appropriately-configured Shared Memory Controller must then only enable writing on the relevant 8 bits of data from the 32-bit word.

When reading, the processor will put the relevant 8- or 16-bit value into the least significant byte positions of the 32-bit word. What happens with the remaining bits depends on the operation:

  • For an unsigned Read, the processor will pad-out the remaining 24 or 16 bits respectively with zeroes.
  • For a byte load/store, the processor will sign-extend from bit 8.
  • For a half-word load/store, the processor will sign-extend from bit 16.

The process described happens transparently because memory devices are always seen by the processor as being 32 bits wide. Even when connecting to small 8- or 16-bit physical memories, the Shared Memory Controller will, as far as the processor is concerned, make the memory look like it is 32 bits wide.

When connecting to 2 x 8-bit or 2 x 16-bit physical memory, the two distinct physical devices are treated as a single memory space. For the common-bus SRAM and SDRAM on a 3-connector daughter board, the Shared Memory Controller uses the MEM_BE[3..0] bus to direct the relevant byte of data to/retrieve the relevant byte of data from, the appropriate byte location at the specified address in memory.

For common-bus SRAM, provided on the daughter board courtesy of the two 16-bit devices designated U4_CM and U5_CM:

  • Byte 0 (i.e. ME_SEL_O(0) and MEM_BE(0)) will be directed to/retrieved from the lower byte of device U4_CM.
  • Byte 1 (i.e. ME_SEL_O(1) and MEM_BE(1)) will be directed to/retrieved from the upper byte of device U4_CM.
  • Byte 2 (i.e. ME_SEL_O(2) and MEM_BE(2)) will be directed to/retrieved from the lower byte of device U5_CM.
  • Byte 3 (i.e. ME_SEL_O(3) and MEM_BE(3)) will be directed to/retrieved from the upper byte of device U5_CM.

For common-bus SDRAM, provided on the daughter board courtesy of the two 16-bit devices designated U2_CM and U3_CM:

  • Byte 0 (i.e. ME_SEL_O(0) and MEM_BE(0)) will be directed to/retrieved from the lower byte of device U2_CM.
  • Byte 1 (i.e. ME_SEL_O(1) and MEM_BE(1)) will be directed to/retrieved from the upper byte of device U2_CM.
  • Byte 2 (i.e. ME_SEL_O(2) and MEM_BE(2)) will be directed to/retrieved from the lower byte of device U3_CM.
  • Byte 3 (i.e. ME_SEL_O(3) and MEM_BE(3)) will be directed to/retrieved from the upper byte of device U3_CM.
You are reporting an issue with the following selected text and/or image within the active document: