Atmel AVR32 user guide: 5.2.1 Virtual Memory Models

Table 2-9. CONFIG1 Fields (Continued)

2.12 Recommended Call Convention

The compiler vendor is free to define a call convention, but seen from a hardware point of view, there are some recommendations on how the call convention should be defined.

Register R12 is intended as return value register in connection with function calls. Some instructions will use this register implicitly. For instance, the conditional ret instruction will move its argument into R12.

AVR32

3. Java Extension Module

The AVR32 architecture can optionally support execution of Java bytecodes by including a Java Extension Module (JEM). This support is included with minimal hardware overhead.

Comparing Java bytecode instructions with native AVR32 instructions, we see that a large part of the instructions overlap as illustrated in Figure 3-1 on page 27. The idea is thus to reuse the hardware resources by adding a separate Java instruction decoder and control module that executes in Java state. The processor keeps track of its execution state through the status register and changes execution mode seamlessly.

In a larger runtime system, an operating system keeps track of and dispatches different processes. A Java program will typically be one, or several, of these processes.

The Java state is not to be confused with the security modes "system" and "application", as the JEM can execute in both modes. When the processor switches instruction decoder and enters Java state, it does not affect the security level set by the system. A Java program could also be executed from the different interrupt levels without interfering with the mode settings of the processor, although it is not recommended that interrupt routines are written in Java due to latency.

The Java binary instructions are called bytecodes. These bytecodes are one or more bytes long. A bytecode consists of an opcode and optional arguments. The bytecodes include some instructions with a high semantic content. In order to reduce the hardware overhead, these instructions are trapped and executed as small RISC programs. These programs are stored in the program memory and can be changed by the programmer (part of the Java VM implementation). This gives full flexibility with regards to future extensions of the Java instruction set. Performance is ensured through an efficient trapping mechanism and "Java tailored" RISC instructions.

Figure 3-1. A large part of the instruction set is shared between the AVR RISC and the Java Virtual Machine. The Java instruction set includes instructions with high semantic contents while the AVR RISC instruction set complements Java's set with traditional hardware near RISC instructions

High level instructions Low level instructions

3.1 The AVR32 Java Virtual Machine

The AVR32 Java Virtual machine consists of two parts, the Java Extension Module in hardware and the AVR32 specific Java Virtual Machine software, see Figure 3-2 on page 28. Together, the two modules comply with the Java Virtual Machine specification.

32000D–04/2011 27

The AVR32 Java Virtual Machine software loads and controls the execution of the Java classes. The bytecodes are executed in hardware, except for some instructions, for example the instructions that create or manipulate objects. These are trapped and executed in software within the Java Virtual Machine.

Figure 3-2. Overview of the AVR32 Java Virtual Machine and the Java Extension Module. The grey area represent the software parts of the virtual machine, while the white box to the right represents the hardware module.

Figure 3-3 on page 29 shows one example on how a Java program is executed. The processor boots in AVR32 (RISC) state and it executes applications as a normal RISC processor. To invoke a Java program, the Java Virtual Machine is called like any other application. The Java Virtual Machine will execute an init routine followed by a class loader that parses the class and initializes all registers necessary to start executing the Java program. The last instruction in the

28 AVR32 32000D–04/2011

class loader is the “RETJ” instruction that sets the processor in the Java state. This means that the instruction decoder now decodes Java opcodes instead of the normal AVR32 opcodes.

Figure 3-3. Example of running a Java program

32000D–04/2011 29

During execution of the Java program, the Java Extension Module will encounter some bytecodes that are not supported in hardware. The instruction decoder will automatically recognize these bytecodes and switch the processor back into RISC state and at the same time jump to a predefined location where it will execute a software routine that performs the semantic of the trapped bytecode. When finished, the routine ends with a “RETJ” instruction. This instruction will make the AVR32 core return to Java state and the Java program will continue at the correct location.

Detailed technical information about the Java Extension module is available in a separate Java Technical Reference document.

30 AVR32 32000D–04/2011

AVR32

4. Secure state

Revision 3 of the AVR32 architecture introduces a secure execution state. This state is intended to allow execution of a proprietary secret code alongside code of unknown origin and intent on the same processor. For example, a company with a proprietary algorithm can program this algorithm into the secure memory sections of the device, and resell the device with the programmed algorithm to an end customer. The end customer will not be able to read or modify the preprogrammed code in any way. Examples of such preprogrammed code can be multimedia codecs, digital signal processing algorithms or telecom software stacks. Whereas previous approaches to this problem required the proprietary code and the end user application to execute on separate devices, the secure state allows integration of the two codes on the same device, saving cost and increasing performance since inter-IC communication is no longer required.

In order to keep the proprietary code secret, this code will execute in a "secure world". The end user application will execute in a "nonsecure world". Code in the nonsecure world can request services from the secure world by executing a special instruction, sscall. This instruction is executed in the context of an API specified by the provider of the proprietary code. The sscall instruction can be associated with arguments passed in registers or memory, and after execution of the requested algorithm, the secure world returns results to the requesting nonsecure application in registers or in memory.

Hardware is implemented to divide the memory resources into two sections, one secure and one non-secure section. The secure section of the memories can only be accessed (read, written or executed) from code running in the secure world. The nonsecure section of the memories can be read, written or executed from the nonsecure world, and read or written from the secure world.

The customer can choose if his application will enable the secure state support or not. An IMPLEMENTATION DEFINED mechanism, usually a Flash fuse, is used to enable or disable secure state support. If this mechanism is programmed so as to disable the secure state, the system will boot in nonsecure world, and its behavior will be identical to previous devices implementing older revisions of the AVR32 architecture. If the system is set up to enable secure state support, the system will boot in the secure state. This allows configuration and startup of the secure world application before execution is passed to the nonsecure world.

4.1 Mechanisms implementing the Secure State

The following architectural mechanisms are used to implement the secure state:

• The sscall and retss instructions are used for passing between the secure and nonsecure worlds.

• The secure world has a dedicated stack pointer, SP_SEC, which is automatically banked into the register file whenever executing in the secure world.

• The SS bit is set in the status register whenever the system is in the secure state. Only sscall and retss can alter this bit.

• Interrupts and exceptions have special handler addresses used when receiving interrupts or exceptions in the secure world. This allows executing the interrupt or exception handler in the secure world, or jumping back into the nonsecure world to execute the handler there.

• A set of secure system registers are used to configure the secure world behavior, and to aid in communication between the secure and nonsecure worlds. These registers can be written when in the secure world, but only read when in the nonsecure world.

32000D–04/2011 31

• When trying to access secure world memories from the nonsecure world, a bus error exception will be raised, and the access will be aborted. Writes to secure system registers from within the nonsecure world will simply be disregarded without any error indication.

• The On-Chip Debug (OCD) system is modified to prevent any leak of proprietary code or data to the nonsecure world. This prevents hacking through the use of the OCD system.

4.2 Secure state programming model

The programming model in the secure state is similar to in normal RISC state, except that SP_SEC has been banked in, and the secure system registers are available in all privileged modes.

Figure 4-1. Register File in AVR32A with secure context

Figure 4-2. Register File in AVR32B with secure context

banked registers (implementation defined) | banked registers (implementation defined) | banked registers (implementation defined) | banked registers (implementation defined)

SS_STATUS SS_ADRF SS_ADRR SS_ADR0 SS_ADR1 SS_SP_SYS SS_SP_APP SS_RAR SS_RSR

4.3 Details on Secure State implementation

Refer to the Technical Reference manual for the CPU core you are using for details on the Secure State implementation.

ATMEL®

32000D–□□/□□□□ 33

34 AVR32 32000D–04/2011

AVR32

5. Memory Management Unit

The AVR32 architecture defines an optional Memory Management Unit (MMU). This allows efficient implementation of virtual memory and large memory spaces. Virtual memory simplifies execution of multiple processes and allows allocation of privileges to different sections of the memory space.

5.1 Memory map in systems with MMU

The AVR32 architecture specifies a 32-bit virtual memory space. This virtual space is mapped into a 32-bit physical space by a MMU. It should also be noted that not all implementations will use caches. The cacheability information specified in the figure will therefore not apply for all implementations. Refer to the implementation-specific Hardware Manual for details.

The virtual memory map is specified in Figure 5-1.

Figure 5-1. The AVR32 virtual memory space

The memory map has six different segments, named P0 through P4, and U0. The P-segments are accessible in the privileged modes, while the U-segment is accessible in the unprivileged mode.

Both the P1 and P2 segments are default segment translated to the physical address range 0x00000000 to 0x1FFFFFFF. The mapping between virtual addresses and physical addresses is therefore implemented by clearing of MSBs in the virtual address. The difference between P1 and P2 is that P1 may be cached, depending on the cache configuration, while P2 is always uncached. Because P1 and P2 are segment translated and not page translated, code for initialization of MMUs and exception vectors are located in these segments. P1, being cacheable, may offer higher performance than P2.

The P3 space is also by default segment translated to the physical address range 0x00000000 to 0x1FFFFFFF. By enabling and setting up the MMU, the P3 space becomes page translated. Page translation will override segment translation.

The P4 space is intended for memory mapping special system resources like the memory arrays in caches. This segment is non-cacheable, non-translated.

The U0 segment is accessible in the unprivileged user mode. This segment is cacheable and translated, depending upon the configuration of the cache and the memory management unit. If accesses to other memory addresses than the ones within U0 is made in application mode, an access error exception is issued.

The virtual address map is summarized in Table 5-1 on page 36.

Table 5-1. The virtual address map

The segment translation can be disabled by clearing the S bit in the MMUCR. This will place all the virtual memory space into a single 4 GB mapped memory space. Doing this will give all access permission control to the AP bits in the TLB entry matching the virtual address, and allow all virtual addresses to be translated. Segment translation is enabled by default.

The AVR32 architecture has two translations of addresses.

1. Segment translation (enabled by the MMUCR[S] bit)

2. Page translation (enabled by the MMUCR[E] bit)

Both these translations are performed by the MMU and they can be applied independent of each other. This means that you can enable:

1. No translation. Virtual and physical addresses are the same.

2. Segment translation only. The virtual and physical addresses are the same for addresses residing in the P0, P4 and U0 segments. P1, P2 and P3 are mapped to the physical address range 0x00000000 to 0x1FFFFFFF.

3. Page translation only. All addresses are mapped as described by the TLB entries.

4. Both segment and page translations. P1 and P2 are mapped to the physical address range 0x00000000 to 0x1FFFFFFF. U0, P0 and P3 are mapped as described by the TLB entries. The virtual and physical addresses are the same for addresses residing in the P4 segment.

The segment translation is by default turned on and the page translation is by default turned off after reset. The segment translation is summarized in Figure 5-2 on page 37.

AVR32

Figure 5-2. The AVR32 segment translation map

5.2 Understanding the MMU

The AVR32 Memory Management Unit (MMU) is responsible for mapping virtual to physical addresses. When a memory access is performed, the MMU translates the virtual address specified into a physical address, while checking the access permissions. If an error occurs in the translation process, or Operating System intervention is needed for some reason, the MMU will issue an exception, allowing the problem to be resolved by software.

The MMU architecture uses paging to map memory pages from the 32-bit virtual address space to a 32-bit physical address space. Page sizes of 1, 4, 64 kilobytes and 1 megabyte are supported. Each page has individual access rights, providing fine protection granularity.

The information needed in order to perform the virtual-to-physical mapping resides in a page table. Each page has its own entry in the page table. The page table also contains protection information and other data needed in the translation process. Conceptually, the page table is accessed for every memory access, in order to read the mapping information for each page.

In order to speed up the translation process, a special page table cache is used. This cache is called a Translation Lookaside Buffer (TLB). The TLB contains the n most recently used page table entries. The number n of entries in the TLB is IMPLEMENTATION DEFINED. It is also IMPLEMENTATION DEFINED whether a single unified TLB should be used for both instruction and memory accesses, or if two separate TLBs are implemented. The architecture supports one or two TLBs with up to 64 entries in each. TLB entries can also be locked in the TLB, guaranteeing high-speed memory accesses.

32000D-04/2011 37

5.2.1 Virtual Memory Models

The MMU provides two different virtual memory models, selected by the Mode (M) bit in the MMU Control Register:

• Shared virtual memory, where the same virtual address space is shared between all processes
• Private virtual memory, where each process has its own virtual address space

In shared virtual memory, the virtual address uniquely identifies which physical address it should be mapped to. Two different processes addressing the same virtual address will always access the same physical address. In other words, the Virtual Page Number (VPN) section of the virtual address uniquely specifies the Physical Frame Number (PFN) section in the physical address.

In private virtual memory, each process has its own virtual memory space. This is implemented by using both the VPN and the Application Space Identifier (ASID) of the current process when searching the TLB for a match. Each process has a unique ASID. Therefore, two different processes accessing the same VPN won't hit the same TLB entry, since their ASID is different. Pages can be shared between processes in private virtual mode by setting the Global (G) bit in the page table entry. This will disable the ASID check in the TLB search, causing the VPN section uniquely to identify the PFN for the particular page.

5.2.2 MMU interface registers

The following registers are used to control the MMU, and provide the interface between the MMU and the operating system. Most registers can be altered both by the application software (by writing to them) and by hardware when an exception occurs. All the registers are mapped into the System Register space, their addresses are presented in Section 2.11 "System registers" on page 14. The MMU interface registers are shown in Figure 5-3.

Figure 5-3. The MMU interface registers

TLBEHI

TLBELO

PTBR

TLBEAR

MMUCR

TLBARLO / TLBARHI

38 AVR32 32000D-04/2011

AVR32

5.2.2.1 TLB Entry Register High Part - TLBEHI

The contents of the TLBEHI and TLBELO registers is loaded into the TLB when the tlbw instruction is executed. The TLBEHI register consists of the following fields:

• VPN - Virtual Page Number in the TLB entry. This field contains 22 bits, but the number of bits used depends on the page size. A page size of 1 kB requires 22 bits, while larger page sizes require fewer bits. When preparing to write an entry into the TLB, the virtual page number of the entry to write should be written into VPN. When an MMU-related exception has occurred, the virtual page number of the failing address is written to VPN by hardware.
• V - Valid. Set if the TLB entry is valid, cleared otherwise. This bit is written to 0 by a reset. If an access to a page which is marked as invalid is attempted, an TLB Miss exception is raised. Valid is set automatically by hardware whenever an MMU exception occurs.
• I - Instruction TLB. If set, the current TLBEHI and TLBELO entries should be written into the Instruction TLB. If cleared, the Data or Unified TLB should be addressed. The I bit is set by hardware when an MMU-related exception occurs, indicating whether the error occurred in the ITLB or the UTLB/DTLB.
• ASID - Application Space Identifier. The operating system allocates a unique ASID to each process. This ASID is written into TLBEHI by the OS, and used in the TLB address match if the MMU is running in Private Virtual Memory mode and the G bit of the TLB entry is cleared. ASID is never changed by hardware.

5.2.2.2 TLB Entry Register Low Part - TLBELO

The contents of the TLBEHI and TLBELO registers is loaded into the TLB when the tlbw instruction is executed. None of the fields in TLBELO are altered by hardware. The TLBELO register consists of the following fields:

• PFN - Physical Frame Number to which the VPN is mapped. This field contains 22 bits, but the number of bits used depends on the page size. A page size of 1 kB requires 22 bits, while larger page sizes require fewer bits. When preparing to write an entry into the TLB, the physical frame number of the entry to write should be written into PFN.
• C - Cacheable. Set if the page is cacheable, cleared otherwise.
• G - Global bit used in the address comparison in the TLB lookup. If the MMU is operating in the Private Virtual Memory mode and the G bit is set, the ASID won't be used in the TLB lookup.
• B - Bufferable. Set if the page is bufferable, cleared otherwise.
• AP - Access permissions specifying the privilege requirements to access the page. The following permissions can be set, see Table 5-2 on page 40.

32000D-04/2011 39

Table 5-2. Access permissions implied by the AP bits

• SZ - Size of the page. The following page sizes are provided, see Table 5-3:

Table 5-3. Page sizes implied by the SZ bits

• D - Dirty bit. Set if the page has been written to, cleared otherwise. If the memory access is a store and the D bit is cleared, an Initial Page Write exception is raised.
• W - Write through. If set, a write-through cache update policy should be used. Write-back should be used otherwise. The bit is ignored if the cache only supports write-through or write-back.

5.2.2.3 Page Table Base Register - PTBR

This register points to the start of the page table structure. The register is not used by hardware, and can only be modified by software. The register is meant to be used by the MMU-related exception routines.

5.2.2.4 TLB Exception Address Register - TLBEAR

This register contains the virtual address that caused the most recent MMU-related exception. The register is updated by hardware when such an exception occurs.

5.2.2.5 MMU Control Register - MMUCR

The MMUCR controls the operation of the MMU. The MMUCR has the following fields:

• IRP - Instruction TLB Replacement Pointer. Points to the ITLB entry to overwrite when a new entry is loaded by the tlbw instruction. The IRP field may be updated automatically in an IMPLEMENTATION DEFINED manner in order to optimize the replacement algorithm. The IRP field can also be written by software, allowing the exception routine to implement a replacement algorithm in software. The IRP field is 6 bits wide, allowing a maximum of 64

entries in the ITLB. It is IMPLEMENTATION DEFINED whether to use fewer entries. Impementations with a single unified TLB does not use the IRP field.

• ILA - Instruction TLB Lockdown Amount. Specified the number of locked down ITLB entries. All ITLB entries from entry 0 to entry (ILA-1) are locked down. If ILA equals zero, no entries are locked down. Implementations with a single unified TLB does not use the ILA field.

• DRP - Data TLB Replacement Pointer. Points to the DTLB entry to overwrite when a new entry is loaded by the tlbw instruction. The DRP field may be updated automatically in an IMPLEMENTATION DEFINED manner in order to optimize the replacement algorithm. The DRP field can also be written by software, allowing the exception routine to implement a replacement algorithm in software. The DRP field is 6 bits wide, allowing a maximum of 64 entries in the DTLB. It is IMPLEMENTATION DEFINED whether to use fewer entries. Implementations with a single unified TLB use the DRP field to point into the unified TLB.

• DLA - Data TLB Lockdown Amount. Specified the number of locked down DTLB or UTLB entries. All DTLB entries from entry 0 to entry (DLA-1) are locked down. If DLA equals zero, no entries are locked down.

• S - Segmentation Enable. If set, the segmented memory model is used in the translation process. If cleared, the memory is regarded as unsegmented. The S bit is set after reset.

• N - Not Found. Set if the entry searched for by the TLB Search instruction (tlbs) was not found in the TLB.

• I - Invalidate. Writing this bit to one invalidates all TLB entries. The bit is automatically cleared by the MMU when the invalidate operation is finished.

• M - Mode. Selects whether the shared virtual memory mode or the private virtual memory mode should be used. The M bit determines how the TLB address comparison should be performed, see Table 5-4 on page 41.

Table 5-4. MMU mode implied by the M bit \begin{tabular}{|l|l|} \hline M & Mode \ \hline 0 & Private Virtual Memory \ \hline 1 & Shared Virtual Memory \ \hline \end{tabular}

• E - Enable. If set, the MMU translation is enabled. If cleared, the MMU translation is disabled and the physical address is identical to the virtual address. Access permissions are not checked and no MMU-related exceptions are issued if the MMU is disabled. If the MMU is disabled, the segmented memory model is used.

5.2.2.6 TLB Accessed Register HI / LO - TLBARHI / TLBARLO

The TLBARHI and TLBARLO register form one 64-bit register with 64 1-bit fields. Each of these fields contain the Accessed bit for the corresponding TLB entry. The I bit in TLBEHI determines whether the ITLB or DTLB Accessed bits are read. The Accessed bit is 0 if the page has been accessed, and 1 if it has not been accessed. Bit 31-0 in TLBARLO correspond to TLB entry 0-31, bit 31-0 in TLBARHI correspond to TLB entry 32-63. If the TLB implementation contains less than 64 entries then nonimplemented entries are read as 0.

Note: The contents of TLBARHI/TLBARLO are reversed to let the Count Leading Zero (CLZ) instruction be used directly on the contents of the registers. E.g. if CLZ returns the value four on the contents of TLBARLO, then item four is the first unused item in the TLB.

32000D-04/2011 ATMEL 41

5.2.3 Page Table Organization

The MMU leaves the page table organization up to the OS software. Since the page table handling and TLB handling is done in software, the OS is free to implement different page table organizations. It is recommended, however, that the page table entries (PTEs) are of the format shown in Figure 5-4. This allows the loaded PTE to be written directly into TLBELO, without the need for reformatting. How the PTEs are indexed and organized in memory is left to the OS.

Figure 5-4. Recommended Page Table Entry format

5.2.4 TLB organization

The TLB is used as a cache for the page table, in order to speed up the virtual memory translation process. Up to two TLBs can be implemented, each with up to 64 entries. Each TLB is configured as shown in Figure 5-5 on page 42.

Figure 5-5. TLB organization

The D, W and AP[1] bits are not implemented in ITLBs, since they have no meaning there. The AP[0] bits are not implemented in DTLBs, since they have no meaning there. The A bit is the Accessed bit. This bit is set when the TLB entry is loaded with a new value using the tlbw instruction. It is cleared whenever the TLB matching process finds a match in the specific TLB entry. The A bit is used to implement pseudo-LRU replacement algorithms. When an address look-up is performed by the TLB, the address section is searched for an entry matching the virtual address to be accessed. The matching process is described in chapter 5.2.5.

5.2.5 Translation process

The translation process maps addresses from the virtual address space to the physical address space. The addresses are generated as shown in Table 5-5, depending on the page size chosen:

Table 5-5. Physical address generation

A data memory access can be described as shown in Table 5-6.

Table 5-6. Data memory access pseudo-code example

If (Segmentation disabled) If (! PagingEnabled) PerformAccess(cached, write-back); else PerformPagedAccess(VA); else if (VA in Privileged space) if (InApplicationMode) SignalException(DTLB Protection, accesstype); endif; endif;

if (VA in P4 space)
    PerformAccess(non-cached);
else if (VA in P2 space)
    PerformAccess(non-cached);
else if (VA in P1 space)
    PerformAccess(cached, writeback);
else
    // VA in P0, U0 or P3 space
    if (! PagingEnabled)
        PerformAccess(cached, writeback);
    else
        PerformPagedAccess(VA);
    endif;
endif;

endif;

The translation process performed by PerformTranslatedAccess( ) can be described as shown in Table 5-7.

Table 5-7. PerformTranslatedAccess( ) pseudo-code example

match ← 0; for (i=0; i<TLBentries; i++) if ( Compare(TLB[i]VPN, VA, TLB[i]SZ, TLB[i]V) ) // VPN and VA matches for the given page size and entry valid if ( SharedVirtualMemoryMode or (PrivateVirtualMemoryMode and ( TLB[i]C or (TLB[i]ASID==TLBEHIASID) ) ) ) if (match == 1) SignalException(TLBmultipleHit); else match ← 1; TLB[i]A ← 1; ptr ← i; // pointer points to the matching TLB entry endif; endif; endfor;

if (match == 0 )
    SignalException(DTLBmiss, accesstype);
endif;

if (InApplicationMode)
    if (TLB[ptr]AP[2] == 0)
        SignalException(DTLBprotection, accesstype);
    endif;
endif;

if (accesstype == write)
    if (TLB[ptr]AP[1] == 0)
        SignalException(DTLBprotection, accesstype);
    endif;
    if (TLB[ptr]D == 0)
        // Initial page write
        SignalException(DTLBmodified);
    endif;
endif;

if (TLB[ptr]C == 1)
    if (TLB[ptr]W == 1)
        PerformAccess(cached, write-through);
    else
        PerformAccess(cached, write-back);
    endif;
else
    PerformAccess(non-cached);
endif;

An instruction memory access can be described as shown in Table 5-8. Table 5-8. Instruction memory access pseudo-code example

If (Segmentation disabled) If (! PagingEnabled) PerformAccess(cached, write-back); else PerformPagedAccess(VA); else if (VA in Privileged space) if (InApplicationMode) SignalException(ITLB Protection, accesstype); endif;

if (VA in P4 space)
    PerformAccess(non-cached);
else if (VA in P2 space)
    PerformAccess(non-cached);
else if (VA in P1 space)
    PerformAccess(cached, writeback);
else
    // VA in P0, U0 or P3 space
    if ( ! PagingEnabled)
        PerformAccess(cached, writeback);
    else
        PerformPagedAccess(VA);
    endif;
endif;

endif;

32000D–04/2011 45

The translation process performed by PerformTranslatedAccess( ) can be described as as shown in Table 5-9.

Table 5-9. PerformTranslatedAccess( ) pseudo-code example

match ← 0; for (i=0; i<TLBentries; i++) if ( Compare(TLB[i]VPN, VA, TLB[i]SZ, TLB[i]V) ) // VPN and VA matches for the given page size and entry valid if ( SharedVirtualMemoryMode or (PrivateVirtualMemoryMode and ( TLB[i]G or (TLB[i]ASID==TLBEHIASID) ) ) ) if (match == 1) SignalException(TLBmultipleHit); else match ← 1; TLB[i]A ← 1; ptr ← i; // pointer points to the matching TLB entry endif; endif; endfor;

if (match == 0 ) SignalException(ITLBmiss); endif;

if (InApplicationMode) if (TLB[ptr]AP[2] == 0) SignalException(ITLBprotection); endif; endif;

if (TLB[ptr]AP[0] == 0) SignalException(ITLBprotection); endif;

if (TLB[ptr]C == 1) PerformAccess(cached); else PerformAccess(non-cached); endif;

46 AVR32 32000D–04/2011

AVR32

5.3 Operation of the MMU and MMU exceptions

The MMU uses both hardware and software mechanisms in order to perform its memory remapping operations. The following tasks are performed by hardware:

1. The MMU decodes the virtual address and tries to find a matching entry in the TLB. This entry is used to generate a physical address. If no matching entry is found, a TLB miss exception is issued.
2. The matching entry is used to determine whether the access has the appropriate access rights, cacheability, bufferability and so on. If the access is not permitted, a TLB Protection Violation exception is issued.
3. If any other event arises that requires software intervention, an appropriate exception is issued.
4. If the correct entry was found in the TLB, and the access permissions were not violated, the memory access is performed without any further software intervention.

The following tasks must be performed by software:

1. Setup of the MMU hardware by initializing the MMU-related registers and data structures if needed.
2. Maintenance of the TLB structure. TLB entries are written, invalidated and replaced by means of software. A tlbw instruction is included in the instruction set to support this.
3. The MMU may generate several exceptions. Software exception handlers must be written in order to service these exceptions.

5.3.1 The tlbw instruction

The tlbw instruction is implemented in order to aid in performing TLB maintenance. The instruction copies the contents of TLBEHI and TLBELO into the TLB entry pointed to by the ITLB or DTLB Replacement Pointers (IRP/DRP) in the MMU Control Register. The TLBEHI[I] bit decides if the ITLB or the DTLB should be addressed. IRP and DRP may in some implementations be automatically updated by hardware in order to implement a TLB replacement algorithm in hardware. Software may update them before executing tlbw in order to implement a software replacement algorithm.

In some implementations, the TLB data structures may be mapped into the P4 space. In such implementations, the TLB data structures may be updated with regular memory access instructions.

5.3.2 TLB synonyms

Implementations using virtually indexed caches may be subject to cache inconsistencies, depending on the page size used and number of lines in the cache. These inconsistencies may occur when multiple virtual addresses are mapped to the same physical address, since a translated part of VPN may be used to index the cache. This implies that the same physical address may be mapped to different cache lines, causing cache inconsistency.

Synonym problems can only appear when addressing data residing in a virtually indexed cache. Addressing uncached memory or accessing untranslated memory will never cause synonym problems.

It is the responsability of the OS to define a policy ensuring that no synonym problems may arise. No hardware support is provided to avoid TLB synonyms.

32000D–04/2011 ATMEL 47

5.3.3 MMU exception handling

This chapter describes the software actions that must be performed for MMU-related exceptions. The hardware actions performed by the exceptions are described in detail in Section 8.3.1 “Description of events in AVR32A” on page 68.

5.3.3.1 ITLB / DTLB Multiple Hit

If multiple matching entries are found when searching the ITLB or DTLB, this exception is issued. This situation is a critical error, since memory consistency can no longer be guaranteed. The exception hardware therefore jumps to the reset vector, where software should execute the required reset code. This exception is a sign of erroneous code and is not normally generated.

The software handler should perform a normal system restart. However, debugging code may be inserted in the handler.

5.3.3.2 ITLB / DTLB Miss

This exception is issued if no matching entries are found in the TLBs, or when a matching entry is found with the Valid bit cleared. The same actions must be performed for both exceptions, but DTLB entries contains more control bits than the ITLB entries.

1. Examine the TLBEAR and TLBEHI registers in order to identify the page that caused the fault. Use this to index the page table pointed to by PTBR and fetch the desired page table entry.
2. Use the fetched page table entry to update the necessary bits in PTEHI and PTELO. The following bits must be updated, not all bits apply to ITLB entries: V, PFN, C, G, B, AP[2:0], SZ[1:0], W, D.
3. The TLBEHI[I] register is updated by hardware to indicate if it was a ITLB or a DTLB miss. The MMUCR[IRP] and MMUCR[DRP] pointers may be updated in an IMPLEMENTATION DEFINED way in order to select which TLB entry to replace. The software may override this value by writing a value directly to MMUCR[IRP] or MMUCR[DRP], depending on which TLB to update.
4. Execute the tlbw instruction in order to update the TLB entry.
5. Finish the exception handling and return to the application by executing the rete instruction.

5.3.3.3 ITLB / DTLB Protection Violation

This exception is issued if the access permission bits in the matching TLB entry does not match the privilege level the CPU is currently executing in. The exception is also issued if the MMU is disabled or absent and non-translated areas are accessed with illegal access rights. The same actions must be performed for both exceptions, but DTLB entries contains more control bits than the ITLB entries.

Software must examine the TLBEAR and TLBEHI registers in order to identify the instruction and process that caused the error. Corrective measures like terminating the process must then be performed before returning to normal execution with rete.

AVR32

5.3.3.4 DTLB Modified

This exception is issued if a valid memory write operation is performed to a page that has never been written before. This is detected by the Dirty-bit in the matching TLB entry reading zero.

1. Examine the TLBEAR and TLBEHI registers in order to identify the page that caused the fault. Use this to index the page table pointed to by PTBR and fetch the desired page table entry.
2. Set the Dirty bit in the read page table entry and write this entry back to the page table
3. Use the fetched page table entry to update the necessary bits in PTEHI and PTELO. The following bits must be updated: V, PFN, C, G, B, AP[2:0], SZ[1:0], W, D.
4. The TLBEHI[I] register is updated by hardware to indicate that it was a DTLB miss. Ensure that MMUCR[DRP] points to the TLB entry to replace. An entry for the faulting page must already exist in the DTLB, and MMUCR[DRP] must point to this entry, otherwise multiple DTLB hits may occur.
5. Execute the tlbw instruction in order to update the TLB entry.
6. Finish the exception handling and return to the application by executing the rete instruction.

32000D–04/2011 49

ATMEL®

50 AVR32 32000D–04/2011