Where Do Memory Maps Come From?

A memory map is the bridge between a system-on-chip (SoC) and the firmware and software that is executed on it. Engineers may assume the map automatically appears, but the reality is much more involved. The union of hardware (HW) and software (SW) demands both planning and compromise. The outcome of this merger will not be fully realized until the magical day when the system comes to life.

The memory map defines how software should address hardware and how it can trigger the primitive operations required to control and monitor the chip functions. To ensure the memory map is correct, software and hardware design teams must coordinate their development effort. Teams are encouraged to develop towards a fixed target utilizing symbolic addresses and macros to isolate each from minor changes to the map. However, given the complexity of modern SoCs, it is difficult to anticipate all the change orders that will come with the designs’ evolution.

How the memory map is constructed

The system memory map is built in two steps. Many functional blocks come with a built-in register map which represents their local address structure. This local map is essentially a list of addresses defined from a zero-base address reference. It indicates where to find the local control and status registers (CSRs) and provides details on the purposes of their various bitfields. Additionally, it defines the rules of how to read, write, and clear those bitfields. Invariably, some of the CSRs are introduced later in the development cycle. They may correspond to added logic in an evolving block or, for legacy functions with no built-in CSRs, to the entire local address map. Furthermore, some added logic such as interrupt control and power management can only be defined at full-chip integration. Of course, all the associated changes to the address space need to be propagated from the HW to the SW world.

The second step starts when the blocks are integrated into the SoC and connected through an interconnect fabric. Each function is assigned its own memory address offset to ensure that it can be uniquely addressed. For instance, if a register in a functional block has a local address of 0xA3, and that block has a memory offset of 0x2000, that register can be addressed at 0x20A3 by the software running on the embedded processor.

What could go wrong

As the HW design evolves, the ground continues to shift underneath the memory map. Configurable functions may regularly be dialed up, dialed down, or duplicated to optimize on-chip bandwidth and latencies. Clocking schemes may be refined to meet key performance and power consumption objectives. Late-stage marketing requirements could be introduced as change requests. Or perhaps the software team may decide it needs better visibility into or control over key functions. Again, even if the teams usually do heroic work to stay on top of all these changes, it is not difficult to see how a mistake could slip through. It could, for instance, arise because of a last-minute “trivial” bug fix for which no one remembered to trigger a rebuild of the memory map or because of a forgotten assumption in the original design which breaks a delicate yet necessary behavior on a derivative design. When these happen, the consequences can be considerable.

What we need

Some mistakes can be debugged and patched quickly in software, while others may be much more subtle and difficult to find. Imagine the elusive scenario where a power domain stays on when it should have turned off. The solution is to automate, as much as possible, the generation of the SoC memory map from the local functions to the global system and to further automate the verification of these complex structures. Regeneration must be push-button to maintain productivity in the ever-tightening time-to-market crunch. When bringing a new SoC into the world, the unforeseen happens. However, it is best to mitigate this risk with an IP and toolset that incorporates this invaluable capability.

For more information, contact Arteris IP.