Patent Description:
The present invention generally relates to address translation, and more specifically to address translation using a translation lookaside buffer.

Avionics equipment operates in an environment with a high rate of atmospheric neutrons. The significant improvements in the reliability of silicon (leading to hard failures) in modern integrated circuits (ICs) means soft errors have become the largest contributor to the expected failure rates of avionics hardware. <NPL> give more information on enhancing instruction TLB resilience to soft errors.

Commercially of the shelf (COTS) processors may be used in atmospheric environments. However, the COTS processor may not be designed for the atmospheric environments. In this regard, the COTS processors may not have protection mechanisms provided in hardware. Therefore, it would be advantageous to provide a device, system, and method that cures the shortcomings described above.

A microprocessor is described, in accordance with one or more embodiments of the present disclosure. In some embodiments, the microprocessor includes a memory management unit (MMU) comprising a page table and a translation lookaside buffer (TLB). The page table maps virtual memory to physical memory. The TLB comprises entries from the page table. Each of the entries comprises descriptors. The TLB is maintained in non-error correcting code (ECC) memory. The MMU is configured according to a plurality of MMU configuration parameters. In some embodiments, the microprocessor includes a cache comprising a software monitor function. In some embodiments, the microprocessor includes one or more CPU cores configured to execute the software monitor function. In some embodiments, the software monitor function causes the one or more CPU cores to copy the descriptors from the TLB to ECC memory. In some embodiments, the software monitor function causes the one or more CPU cores to determine a valid bit of the descriptor is set. In some embodiments, the software monitor function causes the one or more CPU cores to compare the descriptors in the ECC memory with the plurality of MMU configuration parameters to determine whether the TLB has a soft error.

Implementations of the concepts disclosed herein may be better understood when consideration is given to the following detailed description thereof. In the drawings:.

In the following detailed description of embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosure.

Embodiments of the present disclosure are generally directed to a software-based monitor for detecting TLB corruptions where hardware protection mechanisms are not available. The software monitor examines the TLB descriptors periodically to determine the validity of the descriptors, examines fields in the descriptor, and performs a comparison to the MMU configuration parameters. If a mis-compare between the decoded descriptor and the expected MMU configuration is detected, the monitor will report a fault. Since the fault event is considered unrecoverable (i.e., there is no way to detect how far the error may have propagated in the system), the processor should be reset. In the event that a corrupted descriptor is detected, the processor core will be reset. The reset will contribute to the loss-of-function rate but will also remove the TLB contribution to erroneous data.

<CIT>; <CIT>; <CIT>; <CIT>; <CIT>; <CIT>; are incorporated herein by reference in the entirety.

Referring now to <FIG>, a computer system <NUM> is described, in accordance with one or more embodiments of the present disclosure. The computer system <NUM> may include one or more of a microprocessor <NUM>, a system memory <NUM>, a SEU protected memory <NUM>, one or more buses <NUM>, and the like.

The system memory <NUM> may be external to the microprocessor <NUM>. The system memory <NUM> may also be referred to as physical memory. The system memory <NUM> may include any type of memory, such as, but not limited to, dynamic random-access memory (DRAM), static RAM (SRAM), flash memory, and the like. In embodiments, the system memory <NUM> may be error correction coding (ECC) memory. The ECC memory may use an error correction code to detect and correct bit data corruption. For example, the computer system <NUM> may be used in a high integrity application and may include ECC protected system memory.

In embodiments, the system memory <NUM> may maintain master page tables. The master page tables may include an MMU configuration <NUM>, as will be described further herein.

In embodiments, the computer system <NUM> includes SEU protected memory <NUM>. The SEU protected memory <NUM> may maintain a copy of the MMU configuration <NUM>.

The buses <NUM> may couple one or more components of the computer system <NUM> such as, but not limited to, the microprocessor <NUM>, system memory <NUM>, SEU protected memory <NUM>. The buses <NUM> may also be referred to as an external bus and/or a system bus.

The microprocessor <NUM> is now described. The microprocessor <NUM> may include one or more Central Processing Unit (CPU) cores <NUM>, memory management unit (MMU) <NUM>, cache <NUM>, bus interface unit (BIU) <NUM>, internal buses <NUM>, and the like.

The bus interface unit <NUM> may couple the microprocessor <NUM> to the external buses <NUM>. The CPU cores <NUM>, MMU <NUM>, cache <NUM>, and BIU <NUM> may be coupled by the internal buses <NUM> of the microprocessor <NUM>. As may be understood, the computer system <NUM> is not intended to be limited to the architecture of the external buses <NUM> and the internal buses <NUM>.

The microprocessor <NUM> may include any number of the CPU cores <NUM>. The CPU cores <NUM> may execute software instructions maintained in the cache <NUM>.

The cache <NUM> may be on-chip cache memory. Data may be written into the cache <NUM>. Data may also be read from the cache <NUM>. The data may be read from the cache <NUM> at a relatively high speed, as compared to the relatively slow speed of reading from the system memory <NUM>. The cache <NUM> may also be referred to as a primary cache or a level one (L1) cache, although this is not intended to be limiting.

In embodiments, the cache <NUM> may include a software monitor <NUM> function. The software monitor <NUM> may implement one or more methods, as will be described further herein. Although the cache <NUM> is described as including the software monitor <NUM>, this is not intended as a limitation of the present disclosure. In embodiments, the software monitor <NUM> may be executed from a memory location outside of the microprocessor <NUM>. For example, the software monitor <NUM> may be executed directly from the system memory <NUM>, from the SEU protected memory <NUM>, or the like.

As depicted in <FIG>, the cache <NUM> may include one or more memory regions <NUM>. For example, the memory regions <NUM> of the cache <NUM> may include, but are not limited to, regions for executable code 126a, data storage 126b, variable storage 126c, I/O storage 126d, and the like. The software monitor <NUM> may be maintained in the executable code 126a region. The data storage 126b, variable storage 126c, and the I/O storage 126d may not be executable.

In embodiments, each of the memory regions <NUM> may be broken into pages <NUM>. Each of the memory regions <NUM> may include any number of the pages <NUM>. The pages <NUM> may include a size. For example, the size of the pages <NUM> may be <NUM> kB, <NUM> MB, or the like. The pages <NUM> may be configured with configuration parameters (e.g., permissions). Each page <NUM> in a common memory region may include the same configuration parameters. However, each of the pages <NUM> in the common memory region may include a different offset.

In embodiments, the microprocessor <NUM> includes the MMU <NUM>. The MMU <NUM> may be implemented in SRAM or the like. The MMU <NUM> may include a page table <NUM> mapping virtual memory to physical memory. The physical memory may be in system memory <NUM> or the like. The MMU <NUM> may perform a page table walk to find a page in system memory <NUM> containing the associated address and perform virtual address to physical address translation. The MMU <NUM> handles address translation between virtual addresses and physical addresses. The physical address may be in the system memory <NUM> or the like. In embodiments, the MMU <NUM> may include a multi-level page table.

The MMU <NUM> may be configured based on a MMU configuration <NUM>. The MMU configuration <NUM> may set the bits (e.g., descriptors) for a particular address. The MMU configuration <NUM> is stored in ECC memory. The ECC protected memory may be ROM or RAM. For example, the MMU configuration <NUM> may be stored in non-volatile memory (e.g., flash) and/or in system memory <NUM> (e.g., ECC protected memory). The MMU configuration <NUM> may be maintained in the system memory <NUM> and/or in the SEU protected memory <NUM>. The MMU configuration <NUM> may be retrieved from the system memory <NUM> and/or in the SEU protected memory <NUM> during initialization of the microprocessor <NUM>. The MMU <NUM> may be configured during the initialization of the microprocessor <NUM> using the MMU configuration <NUM> in response to retrieving the MMU configuration <NUM>. The MMU <NUM> is configured with memory type and permissions for each defined memory region in a memory map of the microprocessor <NUM>. The MMU configuration <NUM> also maps the virtual memory address range to the physical addresses in the system memory <NUM>.

The MMU <NUM> may include a Translation Lookaside Buffer (TLB) <NUM>. The TLB <NUM> may be a cache inside of the MMU <NUM>. The TLB <NUM> may include recently accessed page translations from the page table <NUM> of the MMU <NUM>. A subset of the most recently used page tables <NUM> may be cached in the TLB <NUM>. The MMU <NUM> may access the TLB <NUM> for fast access to the most recently used page tables <NUM>. The TLB <NUM> may be a cache for virtual address translation. In particular, the TLB <NUM> may be a cache of recently executed page translations within the MMU <NUM>. The TLB <NUM> may include recent page table entries. The entries <NUM> in the TLB <NUM> may provide fast conversion from a virtual address to a physical address, without needing to perform the page table walk of the MMU <NUM>. The TLB <NUM> may comprise an array of the entries <NUM> that map a virtual address region to a corresponding physical address region. The array of the entries <NUM> may include the most recently used physical address regions. When the CPU cores <NUM> access a virtual address, the TLB <NUM> may searched for the page containing the virtual address. If the page is found in the TLB <NUM>, address translation may be performed and the physical address may be accessed. If the page is not found, the MMU <NUM> may perform the page table walk.

In embodiments, the TLB <NUM> may be maintained in non-error correcting code (ECC) memory. In this regard, the entries <NUM> of the TLB <NUM> may be subject to soft errors, as will be described further herein.

The number of the entries <NUM> in the TLB <NUM> may be based on the architecture of the microprocessor <NUM>. For example, the cache may include between <NUM> and <NUM> of the entries <NUM>, although this is not intended to be limiting. Generally, the TLB <NUM> may include any number of the array of the entries <NUM>, such that the exemplary range is not intended to be limiting.

The entries <NUM> may be added and removed from the TLB <NUM> using a replacement algorithm. The replacement algorithm may be utilized to replace an existing page with the page found during the table walk after the MMU <NUM> performs the page table walk. In this regard, the new pages may be added when the new page is not found in the current array of entries in the TLB <NUM>. The replacement algorithm may include, but is not limited to, Least Recently Used (LRU), random, First-In First-Out (FIFO), and the like.

Each entry <NUM> of the TLB <NUM> may include a number of bits. The bits in each entry <NUM> may include one or more descriptors <NUM>. The descriptors <NUM> may also be referred to as TLB descriptor, attributes, or TLB attributes. The bits of the descriptors <NUM> may be predefined for each address level. The bits in the descriptors <NUM> should match the bits in the MMU configuration <NUM> when the TLB <NUM> is not corrupted due to soft error. The specifics regarding the position of and the number of the bits of the descriptors <NUM> may be based on the architecture of the microprocessor <NUM>. In some embodiments, the descriptors <NUM> may be configured according to the ARM™ descriptors (e.g., Cortex-A descriptors), although this is not intended to be limiting.

As depicted in <FIG>, the entries <NUM> in the TLB <NUM> may include one or more descriptors <NUM>. The descriptors <NUM> may include, but are not limited to, physical address 128a, size 128b, virtual address 128c, shareability 128d, execution permissions 128e, security permissions 128f, memory type <NUM>, and the like. Although the descriptors <NUM> are described as including the shareability 128d and the security permissions 128f, this is not intended as a limitation of the present disclosure. For example, the security permissions may or may not be defined. By way of another, the CPU cores may include a single core. The shareability may then not be defined. The physical address 128a, size 128b, virtual address 128c, execution permissions 128e, and memory type <NUM> may be mandatory. The definition of the descriptors <NUM> may be performed by the manufacturer of the microprocessor <NUM>. For example, the descriptors <NUM> may be defined according to one or more standards from ARM™ PowerPC™, Intel™, and the like.

The physical address 128a may represent data from elsewhere in a memory map of the microprocessor <NUM>. For example, the physical address 128a may represent data from the system memory <NUM> or external devices connected to the BIU <NUM>. The virtual address 128c may also be referred to as a logical address. The shareability 128d may be bits of the translation table entry which give permission to share the pages. The execution permissions 128e may be bits of the translation table entry which give permission to execute software. The security permissions 128f may also be referred to as access permissions. The security permissions 128f may be bits in the translation table entry which give access permissions for a page. The memory type <NUM> may be bits of the translation table entry that describes the type of the memory (e.g., the type of the system memory <NUM>). The memory type <NUM> may also describe a memory regions cache-ability and/or allocation policy.

Soft errors are now described. Soft errors may refer to bit flipping (i.e., the unintended flipping of a bit). Soft errors may also be referred to as bit corruption. Soft errors may be recoverable by performing a reset and/or rewriting the bit errors. Bits in the TLB <NUM> may be corrupted due to the soft error.

The soft errors may be caused by one or more sources. For example, the soft errors may be due to single-event upset (SEU). SEU may refer to radiation-induced errors. The radiation-induced errors may be caused by charged particles (usually from the radiation belts or from cosmic rays) ionizing the medium through which they pass, leaving behind a wake of electron-hole pairs. SEU may be relatively more common in avionics and/or space applications, although this is not intended to be limiting. SEU may also occur in terrestrial applications. Although the soft errors are described as being caused by SEU, this is also not intended to be limiting.

In embodiments, the TLB <NUM> may be susceptible to the soft errors. The soft errors may be induced in the TLB <NUM> due to atmospheric neutron incidence with the TLB (e.g., atmospheric neutron incidence with SRAM). The longer an entry remains in the TLB <NUM>, the more susceptible the entry is to soft errors due to SEU corruption. Descriptors related to common code blocks or frequently used data are expected to remain in the TLB <NUM> for long periods of time. The descriptors may remain in the TLB <NUM> even in applications where multiple threads, partitions, or context changes are executed at regular intervals. A portion of the TLB descriptors may remain static. The static descriptors may have a high probability of the soft errors. The percent of persistent TLB entries must be considered when determining the probability of data/instruction corruption.

The soft errors in the TLB <NUM> may lead to undetected erroneous operation of the microprocessor <NUM> and/or the transmission of undetected erroneous data on the buses <NUM>. For example, at least the following scenarios may occur when a bit in an entry of the TLB <NUM> is corrupted by a soft error: a hit with corrupted Physical Address or Memory Attributes, a Pseudo-miss, and/or Pseudo-hit.

A Hit with corrupted Physical Address or Memory Attributes is now described. The Virtual Address of an operation is correctly matched to a TLB entry (hit), but the corresponding Physical Address or memory attributes have been corrupted. The impact would vary depending on whether the transaction was accessing data vs instructions. In the case of instructions, a page worth of instructions would be incorrect, resulting in invalid instruction abort (page contains data not code), prefetch abort (page does not have execute permissions), or ultimately trip a processor watchdog monitor. In the case where the Virtual Address corresponded to data, erroneous operation could occur when the incorrect data is fetched from main memory.

A Pseudo-miss is now described. A TLB entry's virtual address is corrupted and causes a miss when the virtual address would otherwise have matched to a physical address. The miss forces a page table entry to be fetched from main memory. The miss does not result in erroneous operation. However, the miss increases processor latency significantly (up to 100x slower). The miss may also impact deterministic execution of the microprocessor <NUM>. For example, a Worst-Case Execution Time may take longer than expected.

A Pseudo-hit is now described. A corrupted TLB entry incorrectly results in a Virtual Address match, where the Physical Address in the table entry does not in fact correspond to that Virtual Address. The result is the same as the Hit with corrupted Physical Address or Memory Attributes scenario where a hit occurs but the physical address or memory attributes have been corrupted, causing erroneous execution or data.

Methods to reduce the impact of the soft errors on the TLB <NUM> are now described. The methods may include disabling the TLB <NUM>, providing a hardware-based protection mechanisms in the microprocessor <NUM>, and providing a software monitor <NUM> in the microprocessor <NUM>. Much of the present disclosure is directed to the software monitor <NUM>.

In embodiments, the TLB <NUM> may be disabled. The TLB <NUM> may be disabled to prevent the soft errors. However, disabling the TLB <NUM> may result in performance impacts to the microprocessor <NUM>. The performance impacts may be so significant as to render the microprocessor <NUM> practically unusable. For example, access times to the TLB <NUM> are generally on the order of <NUM> core clock cycle compared to approximately <NUM> core clock cycles to access system memory. Disabling the TLB <NUM> has unacceptable performance impacts on the microprocessor <NUM> and is not a practical mitigation in a high-performance embedded system. Therefore, it is desirable to implement a feature in the microprocessor <NUM> to address the soft errors without disabling the TLB <NUM>.

In embodiments, the microprocessor <NUM> includes hardware-based protection mechanisms. The hardware-based protection mechanisms may detect and/or correct for the soft error. For example, the hardware-based protection mechanisms may include, but are not limited to, parity or ECC. However, not all microprocessors may not include the hardware-based protection mechanisms for the MMU <NUM> and/or the TLB <NUM>. Therefore, it may be desirable to implement a software function to address the soft errors in the TLB <NUM>.

In embodiments, the microprocessor <NUM> may include a software monitor <NUM>. The software monitor <NUM> is a software replacement for ECC in the TLB <NUM>. The software monitor <NUM> may be further understood with reference to the various methods described further herein. The CPU cores <NUM> may execute the software monitor <NUM>. The software monitor <NUM> is a software function which detects the soft errors in the TLB <NUM>. The software monitor <NUM> may be particularly advantageous to detect the soft errors in the TLB <NUM> where the microprocessor <NUM> does not include the hardware-based protection mechanisms. The software monitor <NUM> may examine the descriptors <NUM> to determine the validity of the descriptors. The software monitor <NUM> may periodically examine the descriptors <NUM> to determine the validity. The software monitor <NUM> may detect that one or more of the descriptors <NUM> has a soft error.

In embodiments, the software monitor <NUM> may run as a background task on the CPU cores <NUM>. In this regard, the software monitor <NUM> may be run in parallel with and not impact a main processor execution thread. For example, the software monitor <NUM> may run as a background task as part of a health monitor function. For instance, the software monitor <NUM> may run as a <NUM> background thread, although this is not intended to be limiting.

Soft error handling is now described. The soft error handling is performed in response to the software monitor <NUM> detecting that one or more of the descriptors <NUM> has the soft error. The software may determine what to do after the error. The error may be considered a fatal flaw. In this regard, the microprocessor may be unsure what errors occurred and when. For example, erroneous data may be stored in memory region of which the microprocessor may be unaware. To ensure there is no residual erroneous data, reset the microprocessor. In embodiments, the microprocessor <NUM> may be rebooted or reset in response detecting that one or more of the descriptors <NUM> has the soft error. Rebooting the microprocessor may get the microprocessor back into a known state. The reset will contribute to the loss-of-function rate. However, the reset will remove the soft errors in the TLB as contributing to erroneous data. The microprocessor <NUM> may be prevented operating erroneously in response to detecting the soft errors in the TLB <NUM>. Although the microprocessor <NUM> is described as being rebooted or reset, this is not intended as a limitation of the present disclosure. In embodiments, the microprocessor <NUM> may flush the MMU <NUM>, the TLB <NUM>, and/or the cache <NUM> in response to detecting that one or more of the descriptors <NUM> has the soft error. The MMU <NUM>, the TLB <NUM>, and/or the cache <NUM> may then be refilled from the system memory <NUM>.

Various applications of the computer system <NUM> are now described. In embodiments, the computer system <NUM> may be a computer system used in avionics and/or space applications. For example, the computer system <NUM> may be a flight display (e.g., flight display <NUM>), an avionic panel, flight control computer, and the like. The avionics and/or space applications may require medium to high integrity operation of the computer system <NUM>. The software monitor <NUM> may advantageously allow the computer system <NUM> to achieve the medium to high integrity operation by detecting the soft errors of the TLB <NUM>. Although the computer system <NUM> is described as being used in avionics and/or space applications, this is not intended as a limitation of the present disclosure. It is contemplated that the computer system <NUM> may be used in any number of applications to detect soft errors of the TLB <NUM> using the software monitor <NUM>.

Referring now to <FIG>, a schematic illustration of an aircraft <NUM> cockpit <NUM> is shown according to an exemplary embodiment of the inventive concepts disclosed herein. The cockpit <NUM> may include one or more flight displays <NUM>. In embodiments, the flight displays <NUM> may provide an output from an onboard aircraft-based weather radar system, LIDAR system, infrared system or other system on an aircraft. For example, the flight displays <NUM> may include a weather display, a weather radar map, and a terrain display. In embodiments, the flight displays <NUM> may provide an output based on a combination of data received from multiple external systems or from at least one external system and an onboard aircraft-based system. The flight displays <NUM> may include an electronic display or a synthetic vision system (SVS). For example, the flight displays <NUM> may include a display configured to display a two-dimensional (<NUM>-D) image, a three-dimensional (<NUM>-D) perspective image of terrain and/or weather information, or a three-dimensional (<NUM>-D) display of weather information or forecast information combined with forecast information. Other views of terrain and/or weather information may also be provided (e.g., plan view, horizontal view, vertical view). The views may include monochrome or color graphical representations of the terrain and/or weather information. Graphical representations of weather or terrain may include an indication of altitude of the weather or terrain or the altitude relative to an aircraft.

Referring now to <FIG>, a flow diagram of method <NUM> is described, in accordance with one or more embodiments of the present disclosure. The embodiments and the enabling technology described previously herein in the context of the microprocessor <NUM> should be interpreted to extend to the method. For example, the method may be implemented by the microprocessor. The method <NUM> may also be considered one or more steps of the software monitor <NUM>. It is further recognized, however, that the method is not limited to the microprocessor and the monitor function.

In a step <NUM>, memory is allocated for the TLB descriptors <NUM>. The memory is ECC protected. The ECC protected memory may be the system memory <NUM>, on-chip memory (e.g., the cache <NUM>), or another cache.

If there is sufficient memory, the method <NUM> may continue to a step <NUM>. If there is insufficient memory, the method <NUM> may continue to a step <NUM>.

In step <NUM>, the TLB descriptors <NUM> are retrieved. Retrieving the TLB descriptor <NUM> may also be referred to as getting the TLB descriptors <NUM>. The TLB descriptors <NUM> may be retrieved from TLB data registers. The TLB descriptors <NUM> may be retrieved and then stored in the allocated memory location. In this regard, the step <NUM> may include copying the descriptors <NUM> from non-ECC protected memory into ECC protected memory.

In a step <NUM>, the TLB descriptors <NUM> are decoded.

In a step <NUM>, the TLB descriptors <NUM> are validated with the MMU configuration <NUM>. Validating the TLB descriptors <NUM> with the MMU configuration <NUM> may include checking that the TLB descriptors <NUM> match the MMU configuration <NUM>. A valid status is raised when the TLB descriptors <NUM> matches the MMU configuration <NUM>. An error is raised when the TLB descriptors <NUM> do not match the MMU configuration <NUM>. The error indicates system failure (e.g., the soft error in the TLB <NUM>).

In a step <NUM>, the error status is returned in case of failure. The error status is returned to one or more components of the microprocessor <NUM>. For example, the error status may be returned to a health monitor <NUM>. The status is delegated to the health monitor <NUM> such that the health monitor <NUM> may take appropriate action to remedy the soft error (e.g., flush the TLB <NUM>; reset the microprocessor <NUM>, and the like). In case no failure is detected, the method <NUM> repeats. The method <NUM> may continue to monitor the TLB descriptors <NUM> for the soft errors. For example, the method <NUM> may be iteratively performed in a background task of the CPU cores.

In a step <NUM>, the memory is out of memory. In this regard, the step <NUM> does not have sufficient memory to allocate for the TLB descriptors <NUM>. Out of memory may be a corner condition when the memory does not include enough memory to copy the descriptors into a safe location. In response to being out of memory, the method <NUM> may provide an out of memory status indication to the health monitor <NUM>.

The health monitor <NUM> is a central location that monitors health. The health monitor <NUM> may periodically look at status bits and log faults. The health monitor <NUM> may take appropriate action upon receiving a status message indicating an error. For example, the health monitor <NUM> may reboot the microprocessor <NUM> and log the reboot as occurring due to the error. In some embodiments, the health monitor <NUM> may be executed by the CPU cores, although this is not intended to be limiting.

Referring now to <FIG>, a flow diagram of the step <NUM> of getting the TLB descriptor <NUM> is described, in accordance with one or more embodiments of the present disclosure. The step <NUM> may include reading the TLB descriptors <NUM> from the processor registers for each way and each index by accessing the internal processor data registers.

In a step <NUM>, a check is made to determine whether the maximum number of TLB <NUM> way been reached. If the maximum number of the TLB <NUM> way has been reached, then proceed to step <NUM> and exit. If the maximum number of the TLB <NUM> way has not been reached, then proceed to step <NUM>. The TLB <NUM> way is a subdivision of a cache. Each way has an equal size and is indexed in the same fashion. Multiple ways are multiple arrays that can be indexed to the same level.

In a step <NUM>, a check is made to determine whether the maximum number of TLB <NUM> indexes have been reached. If the maximum number of the TLB <NUM> indexes has been reached, then increment the TLB way in a step <NUM> and return to the step <NUM>. If the maximum number of the TLB <NUM> indexes has not been reached, then proceed to step <NUM>. The index is a part of the memory address that determines in which line of the cache the address can be found.

In a step <NUM>, the TLB descriptor <NUM> is read by accessing internal processor data registers.

In a step <NUM>, the TLB descriptor <NUM> is stored in the allocated memory location. For example, the TLB descriptor <NUM> may be stored in the ECC protected memory location.

In a step <NUM>, the TLB index is incremented, then proceed to step <NUM>.

Referring now to <FIG>, a flow diagram of method <NUM> is described, in accordance with one or more embodiments of the present disclosure. The method <NUM> may be a method of the steps <NUM> and <NUM> of decoding the descriptor and validating with the MMU configuration. The method <NUM> may repeat through the entries of the TLB <NUM> until the entries are validated or invalidated.

In the step <NUM>, a check is made to determine whether the maximum number of TLB <NUM> way been reached. If the maximum number of the TLB <NUM> way has been reached, then proceed to step <NUM> and return a status. If the maximum number of the TLB <NUM> way has not been reached, then proceed to step <NUM>.

In the step <NUM>, a check is made to determine whether the maximum number of TLB <NUM> indexes been reached. If the maximum number of the TLB <NUM> indexes has been reached, then increment the TLB way in a step <NUM> and return to the step <NUM>. If the maximum number of the TLB <NUM> indexes has not been reached, then proceed to step <NUM>.

In a step <NUM>, the TLB descriptors <NUM> are read from memory. The TLB descriptors <NUM> are read from the ECC protected memory.

In a step <NUM>, a check is made to determine whether a bit in the descriptors is set to valid. The valid bit indicates that the entry in the TLB <NUM> is actively used. An invalid bit indicates that the entry is not valid. For example, the entry may be invalidated due to never being used. If the valid bit is set, then proceed to a step <NUM>. If the valid bit is not set, then proceed to the step <NUM> and increment the TLB index. If this is a valid entry, then compare entry against master configuration data.

In as step <NUM>, parameters are read from the descriptor. The parameters may include a physical address, a size, a virtual address, a shareability, an execution permission, a security permission, and/or a memory type. Each of the parameters may be defined by one or more bits of the descriptor.

In a step <NUM>, addresses from the TLB descriptor are checked to be within the range of addresses from the MMU configuration <NUM>. The step <NUM> may include checking whether the physical and virtual address obtained from the TLB descriptor falls within the range of physical and virtual address defined in the MMU configuration <NUM>. If the physical and virtual address of the TLB descriptor do not fall within the range of physical and virtual address ranges defined in the MMU configuration <NUM>, then the memory regions have been shifted and proceed to step <NUM> of returning an error status. If the physical and virtual address of the TLB descriptor do fall within the range of physical and virtual address ranges defined in the MMU configuration <NUM>, then proceed to step <NUM>.

In a step <NUM>, the virtual page offset is compared with the physical page offset within the memory range. The step <NUM> may also be referred to as determining whether the page is in the correct offset within the memory region. The step <NUM> checks whether the offsets are the same within the overall memory region. If the virtual page offset matches the physical page offset, then the page is in the correct offset and proceed to step <NUM>. If the virtual page offset does not match the physical page offset, then the page has been shifted within the memory region and proceed to step <NUM> of returning an error status.

The offset is the microregion within the overall region. For example, the region may include <NUM> pages within a region. A wrong offset within the region may point to the wrong data within actual memory. The step <NUM> may include determining the page is within the correct slot in the memory region. One or more calculations may be performed to determine offsets are correct.

In a step <NUM>, if any of the fields in the descriptor don't match the global static parameters for the MMU, proceed to step <NUM> of returning an error status. The fields may include, but are not limited to, shareability 128d, execution permissions 128e, security permissions 128f, and/or memory type <NUM>. If each of the fields in the descriptor do match the global static parameters for the MMU, proceed to step <NUM> and increment the TLB index.

In a step <NUM>, the status of the TLB <NUM> is returned. The status may include a success if the descriptors <NUM> are validated with the MMU configuration <NUM>. The status includes the success if each of the steps <NUM>, <NUM>, and <NUM> are successful. The status may include an error if one or more of the descriptors <NUM> are invalidated with the MMU configuration <NUM>. The status may include the error if the checks in any of the steps <NUM>, <NUM>, and <NUM> fail. The status is delegated to the microprocessor <NUM> to take appropriate action. For example, the microprocessor <NUM> may implement the previously described soft error handling in response to receiving the error (e.g., reset, flush, etc.).

In some embodiments, the steps <NUM>, <NUM>, and <NUM> may immediately proceed to the step <NUM> upon the failure. In this regard, not all entries may be checked for validity upon detecting the errors.

In embodiments, virtual machines (not depicted) can be operated on the computer system <NUM> to perform many different functions. The virtual machines are platform-independent instruction set that allows a user a portable programming environment. Multiple virtual machines can run on the microprocessor <NUM> through sharing or partitioning of the operations of the microprocessor <NUM>. When multiple virtual machines are operating on the microprocessor <NUM>, each virtual machine has its own operating time. There must be isolation between the multiple virtual machines to avoid interaction between them. Partitioning is isolating the two or more virtual machines running on the microprocessor <NUM>.

In some instances, the error detected may impact one or more of the virtual machines but may not impact all of the virtual machines operating on the microprocessor <NUM>. In embodiments, resetting the microprocessor <NUM> may refer to resetting copies of the virtual machine which are detected to have an error with the TLB. The microprocessor <NUM> does not reset copies of the virtual machines which do not have the error. In this regard, operation of the virtual machines without the error may remain uninterrupted.

The methods, operations, and/or functionality disclosed may be implemented as sets of instructions or software readable by a device. The steps may include computations which may be performed simultaneously, in parallel, or sequentially.

A processor may include any processing unit known in the art. For example, the processor may include a multi-core processor, a single-core processor, a reconfigurable logic device (e.g., FPGAs), a digital signal processor (DSP), a special purpose logic device (e.g., ASICs)), or other integrated formats. Those skilled in the art will recognize that aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software/and or firmware would be well within the skill of one skilled in the art in light of this disclosure. Such hardware, software, and/or firmware implementation may be a design choice based on various cost, efficiency, or other metrics. In this sense, the processor(s) may include any microprocessor-type device configured to execute software algorithms and/or instructions. In general, the term "processor" may be broadly defined to encompass any device having one or more processing elements, which execute program instructions from memory, from firmware, or by hardware implemented functions. It should be recognized that the steps described throughout the present disclosure may be carried out by the processors.

A memory may include any storage medium known in the art. For example, the storage medium may include a non-transitory memory medium. For instance, the non-transitory memory medium may include, but is not limited to, a read-only memory (ROM), a random-access memory (RAM), a magnetic or optical memory device (e.g., disk), a solid-state drive and the like. It is further noted that memory may be housed in a common controller housing with the one or more processor(s). For example, the memory and the processor may be housed in a processing unit, a desktop computer, or the like. In an alternative embodiment, the memory may be located remotely with respect to the physical location of the processor. In another embodiment, the memory maintains program instructions for causing the processor(s) to carry out the various steps described through the present disclosure. For example, the program instructions may include a frequency selection algorithm, an HF mission planner, and the like.

Claim 1:
A microprocessor comprising:
a memory management unit "MMU" (<NUM>) comprising a page table and a translation lookaside buffer "TLB" (<NUM>); wherein the page table maps virtual memory to physical memory; wherein the TLB comprises entries from the page table; wherein each of the entries comprises descriptors; wherein the TLB is maintained in non-error correcting code "ECC" memory;
wherein the MMU (<NUM>) is configured according to a plurality of MMU configuration parameters; and characterized in that:
one or more CPU cores (<NUM>) configured to execute a software monitor function, the software monitor function causing the one or more CPU cores to:
copy the descriptors from the TLB to ECC memory;
determine a valid bit of the descriptors is set; and
compare the descriptors in the ECC memory with the plurality of MMU configuration parameters to determine whether the TLB has a soft error.