Electronics Guide

Physical vs. Virtual Addresses

In systems without an MMU, the addresses generated by the processor correspond directly to physical memory locations. When the CPU requests data at address 0x1000, the memory controller accesses physical location 0x1000. This direct mapping is simple and deterministic but limits flexibility.

With an MMU enabled, the processor generates virtual addresses that the MMU translates to physical addresses before memory access occurs. A virtual address of 0x1000 might map to physical address 0x50001000, or any other physical location the system configures. This indirection enables powerful capabilities that would be impossible with direct physical addressing.

The translation process occurs transparently to most software. Application code references virtual addresses without awareness of underlying physical memory organization. Only privileged system software configuring the MMU needs knowledge of the physical memory layout.

Address Space Concepts

Virtual memory creates separate address spaces for different software components. Each process or task can have its own virtual address space, providing the illusion of exclusive access to memory resources. The operating system's address space typically maps differently from application spaces, with privileged regions inaccessible to user code.

The size of virtual and physical address spaces need not match. A 32-bit processor might support 4 GB of virtual address space per process while the physical system contains only 256 MB of RAM. Conversely, systems with Physical Address Extension (PAE) or similar features can address more physical memory than a single virtual address space allows.

In embedded systems, address space sizes are typically smaller than in desktop systems, and the relationship between virtual and physical spaces is often simpler. Many embedded MMUs support 32-bit virtual addresses with direct mapping of most physical memory, reserving virtual memory features for specific protection and isolation needs.

Benefits in Embedded Systems

Virtual memory provides several key benefits that justify its complexity in embedded applications:

Memory protection: The MMU prevents processes from accessing memory outside their allocated regions. A malfunctioning or malicious task cannot corrupt the operating system or other tasks, dramatically improving system reliability and security.

Address space isolation: Each task operates in its own virtual address space, simplifying software development. Different tasks can use identical virtual addresses without conflict, enabling position-independent code and simplifying memory allocation.

Efficient memory utilization: Virtual memory enables flexible physical memory allocation. Non-contiguous physical memory regions can appear contiguous in virtual space. Memory can be allocated on demand, and unused physical pages can be reclaimed.

Hardware abstraction: Software can be developed independently of physical memory layout. The same binary can run on systems with different memory configurations, with only the page tables requiring customization.

Page-Based Translation

Most MMUs divide memory into fixed-size pages, typically 4 KB in size. Virtual and physical address spaces are partitioned into pages, and the MMU maintains mappings between virtual and physical pages. This granularity balances translation table size against flexibility.

A virtual address conceptually divides into two parts: the virtual page number (VPN) identifies which page contains the address, while the page offset specifies the location within that page. The MMU translates the VPN to a physical page number (PPN) while preserving the page offset, producing the physical address.

For a 4 KB page size with 32-bit addresses, the lower 12 bits form the page offset (2^12 = 4096), and the upper 20 bits form the virtual page number. Translation involves looking up the VPN in page tables to find the corresponding PPN, then concatenating the PPN with the unchanged page offset.

Page Table Structure

Page tables store the mappings between virtual and physical pages. The simplest organization uses a single-level page table with one entry per virtual page. For a 32-bit address space with 4 KB pages, this requires 2^20 entries, consuming several megabytes of memory even before considering multiple processes.

Multi-level page tables reduce memory requirements by organizing mappings hierarchically. A two-level system divides the virtual page number into two parts: the first indexes into a page directory that points to page tables, and the second indexes into the page table to find the physical page number. Unused regions of virtual address space require no page table storage, as their page directory entries simply indicate no mapping exists.

ARM processors commonly use two-level page tables with configurable page sizes. The first level (L1) table contains entries pointing to second level (L2) tables or directly mapping large sections (1 MB or larger). This flexibility allows efficient handling of both large contiguous regions and fine-grained mappings.

Modern 64-bit processors may use four-level page tables to handle their vast virtual address spaces, though embedded applications rarely require the full addressing capability.

Page Table Entries

Each page table entry contains more than just the physical page number. Additional fields control access permissions, caching behavior, and other attributes:

Valid bit: Indicates whether the mapping exists. Accessing an invalid entry triggers a page fault exception.

Permission bits: Control read, write, and execute access. Separate bits may govern user-mode and kernel-mode permissions.

Cache attributes: Specify how the processor should cache memory accesses to this page. Options typically include cacheable, write-through, write-back, and non-cacheable.

Access flags: Record whether the page has been accessed or modified, supporting operating system memory management decisions.

Domain or ASID: Associate the mapping with a specific address space or security domain, enabling efficient context switching.

Translation Example

Consider translating virtual address 0x00401234 in a system with 4 KB pages and two-level page tables. The address breaks down as:

Virtual address: 0x00401234

L1 index (upper 12 bits of VPN): 0x004

L2 index (lower 8 bits of VPN): 0x01

Page offset: 0x234

The MMU uses the L1 index to access entry 0x004 in the L1 page table, obtaining a pointer to an L2 page table. It then uses the L2 index to access entry 0x01 in that L2 table, retrieving the physical page number. If the physical page number is 0x80010, the resulting physical address is 0x80010234.

This translation occurs in hardware for every memory access, making efficiency critical. The TLB, discussed later, caches recent translations to avoid repeated page table walks.

Access Permission Levels

Page table entries specify what types of access are permitted for each memory page. Common permission combinations include:

No access: Any access attempt triggers a fault. Used for unmapped regions and guard pages.

Read-only: Read access permitted; write attempts fault. Protects code and constant data.

Read-write: Both read and write access permitted. Used for data regions.

Execute: Instruction fetch permitted. Combined with read-only for code sections.

No-execute: Instruction fetch prohibited even if readable. Prevents code execution from data regions, mitigating certain security attacks.

These permissions often apply differently based on processor privilege level. Kernel-mode code might have full access to a page that user-mode code can only read, or cannot access at all.

Privilege Levels and Domains

Processors define privilege levels that govern access capabilities. ARM processors distinguish between user mode and various privileged modes. The MMU can enforce different permissions based on the current privilege level, allowing the kernel to access all memory while restricting user processes.

Some architectures provide memory domains that group pages with common access characteristics. ARM's domain mechanism associates each page with one of 16 domains, and domain access control registers specify permissions for each domain. This allows rapid permission changes by modifying domain registers rather than individual page table entries.

Trust zones and security extensions add another layer of memory protection. ARM TrustZone partitions memory into secure and non-secure worlds, with hardware preventing non-secure code from accessing secure memory regardless of page table settings.

Fault Handling

When a memory access violates configured permissions, the MMU generates a fault exception. The processor saves its current state and transfers control to the operating system's fault handler, which must determine the cause and take appropriate action.

Common fault responses include:

Terminate the offending process: For protection violations that indicate bugs or malicious behavior.

Demand paging: Valid accesses to not-yet-loaded pages trigger loading from storage.

Copy-on-write: Write faults to shared pages trigger page copying for process isolation.

Stack growth: Accesses near stack boundaries may trigger stack expansion.

In embedded systems, fault handling is often simpler than in general-purpose operating systems. Demand paging is uncommon due to the absence of disk storage, and faults typically indicate software errors requiring logging and possibly system reset.

Memory Protection Units

Some embedded processors include Memory Protection Units (MPUs) rather than full MMUs. An MPU provides access control without address translation, protecting memory regions through a simpler mechanism that requires less hardware and software complexity.

MPUs define a limited number of protection regions (typically 8-16) with configurable base addresses, sizes, and permissions. While lacking virtual memory capabilities, MPUs provide meaningful protection for embedded systems where full virtual memory is unnecessary or too costly.

Many ARM Cortex-M processors include MPUs, enabling protected operating systems like those certified for safety-critical applications. The simpler programming model and deterministic behavior make MPUs attractive for real-time systems.

Cache Architecture Overview

Caches store recently accessed memory contents close to the processor for fast retrieval. Level 1 (L1) caches provide the fastest access, typically split into separate instruction and data caches. Level 2 (L2) and sometimes L3 caches offer larger capacity at slightly higher latency. Caches operate on cache lines, typically 32-64 bytes, loading and storing memory in these fixed-size units.

Cache behavior depends on memory type attributes specified in page table entries. Cacheable memory can be stored in caches, improving performance for frequently accessed data. Non-cacheable memory bypasses caches entirely, ensuring every access reaches main memory. Write-through caches immediately write modified data to memory, while write-back caches defer writes until cache lines are evicted.

Virtual vs. Physical Caching

Caches can index and tag using virtual addresses (VIVT), physical addresses (PIPT), or hybrid schemes (VIPT). Each approach presents different trade-offs:

Virtually indexed, virtually tagged (VIVT): Fast lookup without waiting for address translation, but cache must be flushed on context switch to avoid aliasing problems. Rarely used in modern designs.

Physically indexed, physically tagged (PIPT): No aliasing problems, as physical addresses are unique. However, lookup must wait for MMU translation, adding latency. Common in L2 and L3 caches.

Virtually indexed, physically tagged (VIPT): Enables parallel cache lookup and address translation when index bits come entirely from the page offset. Combines fast lookup with reliable operation. Common in modern L1 caches.

Understanding the cache architecture is essential for embedded systems developers, as it affects both performance optimization and correctness when dealing with DMA and multiprocessor coherency.

DMA and Cache Coherency

Direct Memory Access (DMA) controllers transfer data between peripherals and memory without processor involvement. Since DMA operates on physical addresses and bypasses processor caches, coherency problems arise when cached and DMA-accessible memory regions overlap.

When setting up DMA transfers, software must ensure coherency through one of several approaches:

Cache maintenance operations: Before DMA reads memory that might be cached, software must clean (write back) affected cache lines. Before the processor reads DMA-written memory, software must invalidate affected cache lines. This approach works but adds overhead and complexity.

Non-cacheable buffers: Allocating DMA buffers in non-cacheable memory regions eliminates coherency concerns. Page table attributes mark these regions as non-cacheable. The performance impact depends on access patterns.

Hardware coherency: Some systems include hardware that maintains coherency between caches and DMA. Coherent interconnects snoop cache contents during DMA transfers, eliminating software cache maintenance. This approach simplifies software but requires appropriate hardware support.

Embedded systems designers must carefully choose coherency strategies based on hardware capabilities, performance requirements, and software complexity trade-offs.

Multiprocessor Coherency

Systems with multiple processor cores face additional coherency challenges. When cores have private caches, modifications by one core must become visible to others accessing the same memory locations. Cache coherency protocols ensure consistent memory views across cores.

Common coherency protocols include:

MESI protocol: Cache lines exist in Modified, Exclusive, Shared, or Invalid states. State transitions occur based on local and remote accesses, maintaining coherency through snooping or directory-based mechanisms.

MOESI protocol: Adds an Owned state, allowing one cache to supply data to others without writing back to memory first. Reduces memory bandwidth requirements.

The MMU works with coherency hardware to ensure correct operation. Page table attributes may need to specify shareability, indicating whether a page might be accessed by multiple cores and thus requires coherency protocol participation.

Software memory ordering requirements become complex in multiprocessor systems. Memory barriers ensure operations complete in expected order, and proper synchronization primitives prevent race conditions. Understanding the memory model of the target architecture is essential for correct multiprocessor software.

TLB Organization

TLBs cache page table entries, storing the virtual-to-physical mapping along with permission and attribute information. When the processor needs to translate a virtual address, it first checks the TLB. A TLB hit provides the physical address immediately, while a TLB miss requires a page table walk.

TLB organization varies by processor architecture:

Unified vs. split: Some processors use separate instruction and data TLBs (like split L1 caches), while others use a unified TLB. Split TLBs can serve simultaneous instruction and data accesses but require more hardware.

Fully associative vs. set-associative: Fully associative TLBs can store any translation in any entry, maximizing hit rates but requiring parallel comparison of all entries. Set-associative designs reduce comparison hardware at some cost in hit rate.

Multiple levels: Like data caches, TLBs may have multiple levels. A small, fast L1 TLB handles most translations, with a larger L2 TLB catching misses.

TLB sizes are typically small compared to data caches, ranging from tens to hundreds of entries. The high associativity and large page sizes make this sufficient for most workloads.

TLB Miss Handling

When a TLB miss occurs, the system must walk the page tables to find the required translation. This process can be handled in hardware or software:

Hardware page table walks: The MMU itself traverses page tables and loads the TLB entry. This approach is faster and transparent to software but requires page tables in a hardware-defined format. Most modern processors use hardware walks.

Software TLB miss handling: A TLB miss generates an exception, and software loads the appropriate entry. This provides flexibility in page table format but adds overhead and latency. Some MIPS processors and early ARM designs used software-managed TLBs.

TLB miss latency significantly impacts performance when miss rates are high. Page table organization affects walk time, as does placement of page tables in cacheable memory. Prefetching and other techniques can hide some TLB miss latency in pipelined processors.

TLB Management

Operating systems must manage TLB contents as address mappings change. Key operations include:

TLB invalidation: When page table entries change, corresponding TLB entries must be invalidated to prevent use of stale translations. Architectures provide instructions to invalidate specific entries or the entire TLB.

Context switching: When switching between processes with different address spaces, the OS must handle TLB entries from the old process. Options include flushing the entire TLB (simple but hurts performance) or using address space identifiers.

Address Space Identifiers (ASID): Many processors tag TLB entries with ASIDs identifying the address space. Entries from different address spaces can coexist in the TLB, with only entries matching the current ASID considered for hits. This dramatically improves context switch performance.

Embedded systems typically have simpler TLB management requirements than general-purpose operating systems. With fewer processes and less frequent context switches, aggressive TLB flushing may be acceptable. However, understanding TLB behavior remains important for performance-critical applications.

TLB Performance Optimization

Several techniques improve TLB performance in embedded systems:

Large pages: Using larger page sizes (64 KB, 1 MB, or larger) reduces TLB pressure by covering more memory with fewer entries. This works well for large code or data regions but may waste memory for smaller allocations.

TLB locking: Some processors allow locking critical translations in the TLB, preventing eviction. This guarantees fast access to important memory regions but reduces effective TLB size for other translations.

Memory layout optimization: Arranging code and data to maximize TLB reuse improves hit rates. Keeping hot code paths within a few pages and organizing data structures for spatial locality reduces TLB misses.

Superpages: Some systems automatically combine adjacent small pages into superpages when access patterns suggest benefit. This transparent optimization requires operating system support.

MMU Initialization

MMU initialization typically occurs during system boot and follows a specific sequence:

1. Create initial page tables: Before enabling the MMU, software must create page tables mapping at least the code and data required for continued operation. These tables must reside in physical memory accessible without translation.

2. Configure MMU registers: Set up translation table base registers pointing to page tables, configure domain access controls, and establish default memory attributes.

3. Enable the MMU: Setting the enable bit in the system control register activates address translation. Code immediately following this instruction executes with virtual addressing.

A critical consideration is ensuring the code enabling the MMU is identity-mapped, meaning virtual and physical addresses match. Otherwise, the instruction fetch following MMU enable would fail as the program counter still contains a physical address.

After initial enablement, the operating system typically builds more complete page tables and switches to them, establishing the full virtual memory configuration.

Page Table Management

Operating systems maintain page tables throughout execution, modifying them as processes are created, memory is allocated, and address space configurations change. Key operations include:

Creating address spaces: New processes require new page tables. The operating system allocates page table memory and initializes entries for kernel mappings (often shared across all processes) and initial user mappings.

Memory allocation: When allocating virtual memory, the OS finds free virtual address ranges and creates page table entries mapping them to physical pages. Entries include appropriate permissions and attributes.

Permission changes: Memory protection modifications require updating page table entry permission bits and invalidating affected TLB entries to ensure the new permissions take effect.

Unmapping: Releasing memory involves clearing page table entries and potentially freeing page table memory when entire tables become empty.

Page table operations must be performed carefully to maintain system stability. Races between table modifications and ongoing memory accesses can cause subtle bugs. Proper synchronization and TLB maintenance prevent such issues.

Context Switching

When the operating system switches between processes, it must also switch address space configurations. The context switch procedure includes:

Save processor context: Register contents, including the ASID if used, are saved to the outgoing process's context structure.

Switch page tables: The translation table base register is updated to point to the incoming process's page tables.

Update ASID: If using ASIDs, the current ASID register is updated to match the incoming process.

TLB maintenance: Without ASIDs, the TLB must be flushed. With ASIDs, this step can be skipped unless the ASID has been reused.

Restore processor context: Register contents are restored from the incoming process's context structure.

Minimizing context switch overhead is important for system responsiveness. ASID usage dramatically reduces overhead by eliminating TLB flushes. Sharing kernel page tables across processes also helps, as kernel mappings remain valid after switching.

Real-Time Considerations

MMU operation introduces timing variability that challenges real-time requirements. TLB misses, page table walks, and fault handling all add unpredictable latency to memory accesses. Embedded real-time systems address these challenges through several approaches:

TLB locking: Locking translations for time-critical code and data eliminates TLB miss latency for these accesses.

Static memory allocation: Avoiding runtime memory allocation eliminates page faults during critical sections.

Minimal page table depth: Using large pages and section mappings reduces page table walk time.

Cache locking: Combined with TLB locking, cache locking provides fully deterministic memory access timing.

Worst-case analysis: Real-time analysis must account for worst-case TLB and cache behavior, not just average case.

Some safety-critical systems disable the MMU entirely to achieve maximum timing determinism, accepting the loss of memory protection. Others use MPUs instead, gaining protection without virtual memory's timing variability.

ARM MMU

ARM processors are ubiquitous in embedded systems, and their MMU implementations have evolved across architecture versions:

ARMv7-A: Features two-level page tables with 4 KB, 64 KB, 1 MB, and 16 MB page sizes. Supports 16 memory domains with three access levels per domain. ASID support with 8-bit identifiers enables efficient context switching. The system control coprocessor (CP15) manages MMU configuration.

ARMv8-A: Introduces 64-bit addressing with up to four-level page tables. Supports 4 KB, 16 KB, and 64 KB granule sizes. Replaces domains with a more flexible permission model. Two translation regimes support separate secure and non-secure worlds. ASIDs extend to 16 bits.

ARM processors also support Hardware Access Flag updates, automatically setting access bits in page table entries when pages are accessed. This feature supports operating system memory management but introduces additional memory writes that may affect real-time behavior.

RISC-V MMU

RISC-V, increasingly popular in embedded applications, defines several virtual memory modes:

Sv32: 32-bit virtual addresses with two-level page tables and 4 KB pages. Suitable for embedded systems with moderate memory requirements.

Sv39 and Sv48: 39-bit and 48-bit virtual addresses for larger address spaces, using three and four page table levels respectively.

RISC-V uses the SATP (Supervisor Address Translation and Protection) register to control virtual memory, specifying the page table base and active ASID. The architecture defines a simple, clean interface that facilitates implementation and software development.

PowerPC and Other Architectures

Other processor architectures appear in specialized embedded applications:

PowerPC: Used in automotive, aerospace, and networking applications. Features hash-based page tables (in some implementations) and segment registers providing additional address space control. Book E variants common in embedded systems use more conventional page tables.

MIPS: Historically significant in embedded systems, featuring software-managed TLBs that provide flexibility but require careful software design. Modern MIPS variants include hardware page table walkers.

Understanding the specific MMU features of your target architecture is essential for effective system design. Architectural reference manuals provide detailed specifications, while vendor-provided examples demonstrate practical implementation.

RTOS Virtual Memory Support

Real-time operating systems increasingly support MMU-based memory protection. Examples include:

FreeRTOS with MPU support: Provides task isolation using MPU regions on Cortex-M processors. Recent versions add MMU support for Cortex-A devices, enabling process-like isolation.

Zephyr: Supports both MPU and MMU configurations, providing memory protection suitable for various embedded processors. User-mode support enables running untrusted code with restricted permissions.

QNX: A microkernel RTOS with full virtual memory support, widely used in automotive and medical applications where memory protection is essential.

VxWorks: Provides optional MMU support with real-time performance, supporting both flat and virtual memory models.

RTOS implementations typically offer simplified virtual memory models compared to general-purpose operating systems. Static allocation and fixed mappings are common, avoiding the complexity and timing variability of demand paging.

Linux Virtual Memory

Embedded Linux provides full virtual memory capabilities, making it suitable for complex applications where sophisticated memory management justifies the overhead:

Process isolation: Each process has a private virtual address space, with the kernel enforcing protection between processes and from user space to kernel space.

Demand paging: Memory is allocated and mapped only when accessed, supporting systems where virtual memory exceeds physical memory.

Memory-mapped files: Files can be mapped into process address spaces, providing convenient and efficient file access.

Shared memory: Multiple processes can share memory regions for efficient inter-process communication.

For real-time embedded applications, Linux's PREEMPT_RT patches and careful system configuration can provide reasonable latency bounds, though not as deterministic as specialized RTOSs. Understanding virtual memory behavior helps optimize real-time Linux systems.

Bare-Metal MMU Programming

Some embedded applications program the MMU directly without operating system abstraction. This approach provides maximum control and minimal overhead but requires careful implementation:

Page table construction: The application builds page tables at boot time, typically with static mappings determined at compile time or from configuration data.

Protection configuration: Memory regions are configured with appropriate permissions to protect critical code and data from corruption.

Cache management: The application explicitly manages cache and TLB operations when memory mappings or attributes change.

Vendor-provided startup code and examples often include MMU configuration for their evaluation boards. These serve as starting points for custom implementations.

Common Issues

Several categories of problems commonly arise with MMU usage:

Page faults: Unexpected faults indicate missing mappings, incorrect permissions, or software bugs accessing invalid addresses. Fault handler logging of the faulting address and access type helps diagnosis.

Cache coherency failures: Symptoms include corrupted data, DMA failures, and multiprocessor synchronization issues. These often manifest intermittently, making diagnosis difficult.

TLB inconsistency: Failure to invalidate TLB entries after page table modifications causes unpredictable behavior as stale translations may or may not be used depending on TLB contents.

Permission errors: Code that works with MMU disabled may fail when protection is enabled, revealing bugs that previously caused silent corruption.

Debugging Tools and Techniques

Several approaches assist in debugging MMU issues:

JTAG debuggers: Hardware debuggers can display TLB contents, page table entries, and MMU register values. They can also catch fault exceptions for detailed analysis.

Exception handlers: Well-instrumented exception handlers log essential information including fault address, access type, processor state, and call stack for post-mortem analysis.

Systematic testing: Testing with MMU disabled can isolate whether issues stem from MMU configuration or other causes. Incremental enablement of MMU features helps identify which aspect causes problems.

Memory mapping visualization: Tools that dump and display page table contents help verify correct configuration. Some debuggers provide graphical views of address space mappings.

Best Practices

Following established practices reduces MMU-related problems:

Start simple: Begin with identity mappings and minimal protection, adding complexity incrementally.

Use proven code: Leverage vendor-provided or well-tested MMU initialization code rather than writing from scratch.

Document mappings: Maintain clear documentation of intended memory map and protection scheme.

Consistent cache management: Establish and follow consistent rules for cache maintenance, particularly around DMA operations.

Test thoroughly: Include MMU-specific tests in validation suites, including fault injection and boundary conditions.