Thought Leadership

Memory Management Units

It is curious to consider some technology that, to many engineers, is rather mysterious, whilst, to others, is indispensable. The same technology is conceptually simple, but may be incredibly complex in its implementation. I am thinking about a Memory Management Unit [MMU] …

During its operation a CPU generates a sequence of addresses, along with a a read/write signal, indicating the memory location or peripheral device register that it wishes to access. An MMU’s job is to take the address asserted by the CPU and translate [map] it to an alternative address. This permits a separation of “virtual addresses” [used by the software on the CPU] and “physical addresses” [used by the memory and peripheral hardware.

Obvious question: why is this remapping desirable, useful or necessary?

The most common use of an MMU is to facilitate deployment of a “process model” operating system, like Linux. In this case, each task has one or more dedicated areas of memory for its code and data. When a task is made current by the scheduler, the MMU maps these physical addresses onto a logical address area starting from 0. All the physical memory belonging to other tasks [processes] and to the OS itself is hidden from view and, thus, protected. Each process behaves as if it has free use of the entire CPU. Although this mechanism is safe and elegant, it has the drawback that there is an overhead – the MMU remapping – on every context switch. It follows that having an MMU is essential if Linux is to be used.

Another way to use an MMU is to implement “thread protected mode” or “lightweight process model”. In most RTOSes, an MMU has not been traditionally used and all memory is visible at all times. If the MMU is set up appropriately, parts of the mapping may be switched off as each task is scheduled. Thus, no remapping of addresses occurs, but only the memory for the current task, and relevant parts of the OS, is visible at any one time. This provides much of the protection of process model, with a lower overhead on each context switch. This capability is only available with certain RTOS products, such as Nucleus.

Colin Walls

I have over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv

More from this author

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.stage.sw.siemens.com/embedded-software/2020/08/10/memory-management-units/