Defining the Memory Map for a 32-bit Processor

Frozen Content

An area that can be difficult to manage in an embedded software development project is the mapping of memory and peripherals into the processor's address space.

The memory map, as it is often called, is essentially the bridge between the hardware and software projects – the hardware team allocating each of the various memory and peripheral devices their own chunk of the processor's address space, the software team then writing their code to access the memory and peripherals at the given locations.

To help manage the process of allocating devices into the space there are a number of features available to both the hardware designer and the embedded software developer in Altium Designer.

Building the Bridge between the Hardware and Software

Defining the memory map on the hardware (FPGA project) side is essentially a 3 stage process:

  • Place the peripheral or memory
  • Define its addressing requirements (this is most easily done using an Interconnect component)
  • Bring that definition into the processor's configuration, which can then be accessed by the embedded tools.

Figure 1 shows an example of the addressable memory and IO space for a 32-bit processor, with a number of memory and peripheral devices mapped into it.

Figure 1. A 32-bit processor's 2 ^32^ addressable space (left) and the current set of memory and peripheral devices that
have been mapped into it (right).

The flow chart in Figure 2 shows the process that was followed to build this memory map in the FPGA project. This flow chart is only a guide, during the course of development it is likely that you will jump back and forth through this process as you build up the design.

Figure 2. The flow of connecting
and mapping the peripherals (or
memory) to the processor in an
OpenBus System-based or
schematic-based FPGA design.

Dedicated System Interconnect Components

This process of being able to quickly build up the design and resolve the processor to memory & peripheral interface is possible because of specialized interconnection components. In an OpenBus System, these are the Interconnect and Arbiter components. On the schematic, these are the Wishbone Interconnect and the Wishbone Multi-Master.

These components solve the common system interconnect issues that face the designer, these being:

  • Interfacing multiple peripheral and memory blocks to a processor (handled by the Interconnect component)
  • Allowing two or more system components, that must each be able to control the bus, to share access to a common resource (provided by the Arbiter/Wishbone Multi-Master components).

Use of the Wishbone Interconnection Architecture for all parts of the system that connect to the processor contributes to the system's 'building block' behavior. The Wishbone standard resolves data exchange between system components – supporting popular data transfer bus protocols, while defining clocking, handshaking and decoding requirements (amongst others).

With the lower-level physical interface requirements being resolved by the Wishbone interface, the other challenge is the structural aspects of the system – defining where components sit in the address space, providing address decoding, and allocating and interfacing interrupts to the processor.

Configuring Processor Address Space

Each configurable component has its own configuration dialog, including the different processors. The processor has separate commands and dialogs to configure memory and peripherals, but it does support mapping peripherals into memory space (and the memory into peripheral space), if required.

When building the processor system using an OpenBus System document, mapping of memory and peripheral devices into the processor's address space, based on defined settings for attached interconnects, is handled automatically and dynamically. For schematic-based design, although the mapping is not automated, you can quickly build the memory map for the processor by using the Import from Schematic button in the processor's Configure dialogs. Clicking this will read in the settings from the Interconnects attached to the processor. You now have the memory map defined in the hardware, this data is stored with the processor component.

The processor's Configure dialogs include options to generate assembler and C hardware description files that can be included in your embedded project, simplifying the task of declaring peripheral and memory structures in your embedded code. You can also 'pull' the memory map configurations directly into the embedded project by enabling the Automatically import when compiling FPGA project option on the Configure Memory tab of the Options for Embedded Project dialog.

See Also

For more information on the OpenBus System-based Interconnect and Arbiter components, see OpenBus Interconnect Component and OpenBus Arbiter Component, respectively.

For more information on the schematic-based Wishbone Interconnect and Wishbone Multi-Master components, see WB_INTERCON - Configurable Wishbone Interconnect and WB_MULTIMASTER - Configurable Wishbone Multi-Master, respectively.

For more information on mapping physical memory devices and I/O peripherals into the processor's address space, see Allocating Address Space in a 32-bit Processor.

 

You are reporting an issue with the following selected text and/or image within the active document: