Patent Description:
Microcontrollers are useful for automated processes that can be written into a coded set of instructions that the microcontroller can execute to carry out the desired process. For example, microcontrollers may be used in vehicle engine control systems, biomedical devices, remote controllers, appliances, electric power tools, etc..

Microcontrollers may contain at least one central processing unit (CPU) as well as memory and programmable input/output devices. The memory may be random access memory (RAM), ferroelectric random-access memory (FRAM), non-exclusive OR (NOR) flash, one-time programmable read only memory (OTP ROM), etc. The memory may be external to the CPU. Alternatively, the memory and the CPU may be native on the same device.

The ability to regulate various processes by controlling the passage of data between processors and memory makes microcontrollers an integral part of automated systems. <CIT> discloses a safe memory storage by internal operation verification. <CIT> relates to a parity-based error detection in a memory controller. <CIT> relates to an address error detection technique for increasing the reliability of a storage subsystem. <CIT> relates to a soft error detection and correction by <NUM>-dimensional parity.

Certain examples disclosed herein provide increased protection from faults that may occur between the initial generation of an address information and the decoding of that address information into specific word-line enable values and bit-line enable values. An example system includes a first parity generator, a second parity generator, and a parity checker. The first parity generator is to generate a first parity based on a first address information. The first address information corresponds to a desired location to store data in a memory storage array. The second parity generator is to generate a second parity based on a second address information. The second address information corresponding to an actual location where the data is stored in the memory storage array. The parity checker is to compare the first parity and the second parity to detect a fault. The invention is defined in the appended independent claims. Further preferred embodiments of the invention are defined in the dependent claims.

The figures are not to scale. In general, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts. Although the figures show layers and regions with clean lines and boundaries, some or all of these lines and/or boundaries may be idealized. In reality, the boundaries and/or lines may be unobservable, blended, and/or irregular.

Microcontrollers play an essential role in the automation of processes. The processes can be redundant or critical to the success of an application; regardless of this, proper functionality of the microcontroller is paramount. Typical faults that occur in microcontrollers can arise from electrical or magnetic interference in a memory storage array or the peripheral devices supporting the memory storage array. These interferences can cause one or more bits in memory or logic to change state thereby causing a fault to occur. Typical solutions to these faults are error correcting code (ECC) and parity logic and/or software. These solutions work well under the assumption that the data was written to the correct address and are often accompanied by a read back of the written data after writing. However, even if the address information presented by the CPU is included into the ECC and/or parity logic generation algorithm, if a permanent fault exists in the address path, there is no guarantee that the detection scheme will be able to sense the fault and alert the processor to employ fault correcting procedures without significant delay. The ECC and parity logic and/or software may be, for example, data parity, data and address parity, data ECC, or data and address ECC.

The traditional method of detecting permanent address faults involves testing the memory during startup to make sure the address locations are correct. However, this method is only capable of detecting faults that occurred since the last start-up procedure. Furthermore, the start-up procedure may be infrequently executed, and thus permanent faults may remain undetected for extended periods of time.

For example, the CPU may intend to write some data to a first address, but a fault is present in the address path or logic. This fault will cause the data to be written to a second address instead. If the fault is a transient fault, then the traditional read-after-write method mentioned above would read the data stored at the first address and recognize that the stored data at the first address is not the same data that was transmitted on the write process. However, if the fault is a permanent fault that occurs between the CPU and the ECC and/or parity logic and/or software, the traditional method will perceive that it is reading the data stored at the first address, but it will really be reading the data that is stored at the second address. In the case where the permanent fault occurs between the CPU and the ECC and parity logic and/or software, the data at the second address will be overwritten with the data intended for the first address. The CPU will be unable to determine that the data at the second address has been overwritten and this can cause unsafe conditions in an application.

Another case of a permanent fault is one in which the fault occurs between the ECC and/or parity logic and/or software and the memory. In this case, the traditional method would perceive that the data intended for the first address was stored at the first address, even though it was stored at the second address. When the second address is read by the CPU, the CPU would note that the data stored at the second address was not the correct data for that address. While this type of permanent fault would eventually be caught by the traditional methods, detection would be delayed and leave the application open to unsafe conditions.

To address permanent faults that occur between the CPU and the memory cell the data is stored in, a parity generator may be included in the processor as well as in the memory to generate at least two parities from the address information used in the processor as well as the address information where data is stored in the memory. The processor can then use a parity checker to compare the two or more parity values and determine if a permanent fault has occurred between the address information generation and the address information where the data is stored in the memory. The proposed method of generating a first parity for the address information generated in the processor and comparing that parity to a second parity generated from the address information used to store data in the memory may be used in conjunction with the traditional methods of ECC and parity logic and/or software.

<FIG> is a block diagram of an example fault detection system <NUM> that can be implemented in accordance with the teachings of this disclosure to perform fault detection of an example memory storage array <NUM>. The fault detection system <NUM> may include example processor <NUM> and example memory <NUM>. In the illustrated example, the processor <NUM> is an example central processing unit (CPU) and the memory <NUM> is, for example, RAM. Alternatively, the memory <NUM> may be any other type of volatile or non-volatile memory or logic register.

In the illustrated example of <FIG>, the CPU <NUM> may include an example address generation unit <NUM>.

The address generation unit <NUM> is coupled to an example write address bus <NUM>. The write address bus <NUM> conveys information identifying a desired location, known as an address information, to write data to the memory <NUM>. The data is to be written to the memory <NUM> by an example write data bus <NUM>. The write address bus <NUM> is also coupled to an example CPU parity generator <NUM>. The CPU parity generator <NUM> is coupled to an example parity checker <NUM> by the CPU parity generator output <NUM>. The parity checker <NUM> is then coupled to a part of the CPU <NUM> that is external to the parity checker <NUM>. The CPU <NUM> also includes ECC and/or parity logic and/or software <NUM> that is coupled to the memory <NUM> by the example ECC and parity bus <NUM>. The coupling between different components listed above can be either wired or wireless depending on the application.

In the illustrated example of <FIG>, the CPU <NUM> includes the address generation unit <NUM>. In some examples, the address generation unit <NUM> functions to perform the necessary calculations to address data operands in the CPU and generate addresses. The address generation unit <NUM> includes four sets of register triplets as well as a full adder, an offset adder, and a modulo adder. The register triplets each include an address register, an offset register, and a modifier register. The adders function in conjunction with the registers to perform operations upon the information stored in the registers to generate address information. The address generation unit <NUM> may represent the information as a variety of datatypes including hashed values, binary values, hexadecimal values, etc..

In the illustrated example, the CPU <NUM> includes the CPU parity generator <NUM> that determines at least one parity bit from a certain input data type. As explained below, the parity bit is used to check for single-bit errors in the data from which the parity bit is generated. The CPU <NUM> also includes a parity checker <NUM> that compares at least two parity bits from two different parity generators. After comparing the parity bits, the parity checker <NUM> is to communicate with a different portion of the CPU <NUM> and communicate the result of the parity check.

In the illustrated example of <FIG>, the write address bus <NUM> and the write data bus <NUM> can be implemented in a variety of ways. The write address bus <NUM> and the write data bus <NUM> transmit address information and data to a desired location in a memory storage array <NUM>. Example implementations of the address and data busses may include using one wire for each data or address information value on the bus, using multiplexers as a method of reducing the complexity of the wiring configuration, etc..

In the illustrated example, the memory <NUM> includes an address decoder <NUM>, a memory storage array <NUM>, an address encoder <NUM>, and a memory parity generator <NUM>. The address decoder <NUM> is coupled to the write address bus <NUM> and is coupled to the memory storage array <NUM> by the word-lines <NUM> and the bit-lines <NUM>. The memory storage array <NUM> is coupled to the address encoder <NUM> by the word-lines <NUM> and the bit-lines <NUM>. The address encoder <NUM> is also coupled to the memory parity generator <NUM>. The memory parity generator <NUM> is coupled to the parity checker <NUM> in the CPU <NUM>.

The address decoder <NUM> may include hardware or software elements to convert the datatype of the address information to the required input datatype for the memory storage array <NUM>. This conversion may be done through the use of physical logic gates or through the use of Boolean algebra in software. As a hardware implementation, the address decoder <NUM> may include a number of demultiplexers that convert the signals on the write address bus <NUM> into a greater number of signals that are then used to energize the word-lines <NUM> and the bit-lines <NUM>.

The energized word-lines <NUM> and bit-lines <NUM> create a set of word-line enable values and a set of bit-line enable values that are used to specify an actual location in the memory storage array <NUM> for storage of the information on the write data bus <NUM>.

In the illustrated example of <FIG>, the memory storage array <NUM> may be a programmable logic array, field programmable gate array, etc. that is used in the memory <NUM>. The memory <NUM> may be implemented as a dynamic random-access memory (DRAM), static random-access memory (SRAM), hard drive, etc. In the illustrated example, the word-lines <NUM> and the bit-lines <NUM> are used as designators for row-column pairs that select specific address information in the memory storage array <NUM> to store data. The memory storage array <NUM> may be used in an example memory <NUM> that is DRAM. If the example memory storage array <NUM> is DRAM, then it may include several switches and capacitors. The switches may be transistors such as metal oxide semiconductor field effect transistors (MOSFET), bipolar junction transistors (BJT), junction gate field effect transistors (JFET), heterojunction bipolar transistors (HBT), etc. The usage of a transistor and capacitor together forms a memory cell which corresponds to a single bit of data. The word-lines <NUM> and the bit-lines <NUM> are used to specify the location of individual memory cells in which to store data. The capacitors in the example memory storage array <NUM> may experience leakage over time that would compromise the data that is stored in them and may require re-charging to maintain stored data after a read event. This is done by the re-energizing of the word-lines <NUM> and the bit-lines <NUM> to recharge the capacitors in the memory storage array <NUM>. This repeated re-energization can cause strain on the word-lines <NUM> and bit-lines <NUM> and eventually cause faults to occur on the word-lines <NUM> and/or bit-lines <NUM>.

In the illustrated example of <FIG>, the memory <NUM> includes the address encoder <NUM> that will encode the information on word-lines and bit-lines, <NUM> and <NUM> respectively. The particular set of word-lines <NUM> and bit-lines <NUM> that are enabled become word-line enable values and bit-line enable values that are then to be encoded into address information by the address encoder <NUM>. For example, the word-line enable values and bit-line enable values on the word-lines <NUM> and the bit-lines <NUM> are input (e.g. the values are input) into a multiplexer to reduce the size of the address information being sent to the memory parity generator <NUM> on the address check bus <NUM>. After the re-encoded address information is sent to the memory parity generator <NUM>, the output of the memory parity generator <NUM> is to be sent parity checker <NUM>. The memory parity generator <NUM> is coupled to the parity checker <NUM> so that the output from the memory parity generator <NUM> may be compared to the parity generated from the CPU parity generator <NUM> in the CPU <NUM>. In other words, if there are no faults, the output from the address encoder <NUM> will match the output from the address generation unit <NUM>. The generation of a parity in the CPU <NUM> by the CPU parity generator <NUM>, the generation of a parity in the memory <NUM> by the memory parity generator <NUM>, and the comparison of the two parities by the parity checker <NUM> will allow for proper fault detection of faults that occur between the CPU <NUM> and the location where data is stored.

In the illustrated example of <FIG>, the fault detection system <NUM> actively detects faults on address lines. The desired address information to store data in the memory <NUM> is initially calculated by the address generation unit <NUM>. This address information corresponds to the desired location to store the data on the write data bus <NUM>. The address information is then sent to the write address bus <NUM> and sent to the memory <NUM> as well as to the CPU parity generator <NUM>. The CPU parity generator <NUM> generates one or more parity bits from the encoded address information on the write address bus <NUM>. The one or more parity bits are sent to the parity checker <NUM>.

In the memory <NUM>, the address decoder <NUM> receives the address information from the write address bus <NUM>. The address decoder <NUM> decodes the address information through the use or hardware or software. The decoded address information generates word-line enable values and bit-line enable values on the word-lines <NUM> and bit-lines <NUM> that determine the actual address information where the data on the write data bus <NUM> is to be stored. The word-line enable values and bit-line enable values are then encoded through the use of hardware or software by the address encoder <NUM>. This address information is sent to the memory parity generator <NUM> on the address check bus <NUM>. The memory parity generator <NUM> generates one or more parity bits from the address information it receives.

The one or more parity bits are sent to the parity checker <NUM> in the CPU <NUM> over the memory parity generator output <NUM>. The one or more parity bits generated by the memory parity generator <NUM> are compared to the one or more parity bits generated by the CPU parity generator <NUM>. The result is then sent to a part of the CPU <NUM> that is external from the parity checker <NUM>. The result of the comparison in the parity checker <NUM> may be a digital high value or a digital low value. For example, if the result is a digital high value and the CPU <NUM> is designed such that a digital high value corresponds to a Boolean true value, the CPU <NUM> will be notified that a fault has occurred. Alternatively, if the CPU <NUM> is designed such that a digital high value corresponds to a Boolean false value, then the CPU <NUM> will be notified that no fault has occurred. If no fault has occurred, the CPU <NUM> will continue to check for faults. However, if a fault has occurred, the CPU <NUM> will enact software to mitigate the effects of the error on the application.

<FIG> is a block diagram of the example CPU parity generator <NUM> of <FIG>. The CPU parity generator <NUM> included an example interface <NUM> and an example logical determiner <NUM>. In the example, the interface <NUM> is coupled to the write address bus <NUM> and the logic determiner <NUM>. The logical determiner <NUM> may be coupled to the parity checker <NUM> by the CPU parity generator output <NUM>. The coupling between different components listed above can be either wired or wireless depending on the application.

In the illustrated example of <FIG>, the interface <NUM> may be implemented in hardware as the connection between the write address bus <NUM> and the CPU parity generator <NUM>. The interface <NUM> may separate the address information on the write address bus <NUM> into sections of <NUM> bits of information. The interface <NUM> may alternatively be implemented as software that fulfills the same function. The interface <NUM> may be connected to various datatypes including binary, hexadecimal, octal, etc. The interface <NUM> may convert one of the datatypes to whichever datatype the logical determiner <NUM> may take as an input.

In the illustrated example, the logical determiner <NUM> may be implemented as a set of individual exclusive OR (XOR) gates or as a software Boolean equation that reduces the input value into at least one parity bit or as another type of software that would reduce the input data to a set of parity bits. When implemented with XOR gates, the logical determiner <NUM> may hash groups of eight bits together to form a single parity bit for each group.

<FIG> is a block diagram of the example memory parity generator <NUM> of <FIG>. The memory parity generator <NUM> may include an example interface <NUM> and an example logical determiner <NUM>. The interface <NUM> may be coupled to the address check bus <NUM>. The logical determiner <NUM> is further coupled to the parity checker <NUM> by the memory parity generator output <NUM>. The coupling between different components listed above can be either wired or wireless depending on the application.

In the illustrated example of <FIG>, the interface <NUM> may be implemented in hardware as the connection between the write address bus <NUM> and the memory parity generator <NUM>. The interface <NUM> may separate the address information on the write address bus <NUM> into sections of <NUM> bits of information. The interface <NUM> may alternatively be implemented as software that fulfills the same function. The interface <NUM> may be connected to various datatypes including binary, hexadecimal, octal, etc. The interface <NUM> may convert one of the datatypes to whichever datatype the logical determiner <NUM> may take as an input.

<FIG> is a block diagram of the example parity checker <NUM> of <FIG>. The parity checker <NUM> includes an example interface <NUM>, an example comparator <NUM>, and an example fault generator <NUM>. The interface <NUM> is coupled to a part of the CPU <NUM> that is external to the parity checker <NUM>, the CPU parity generator output <NUM>, the memory parity generator output <NUM>, etc. The coupling between different components listed above can be either wired or wireless depending on the application.

In the illustrated example of <FIG>, the interface <NUM> is coupled to the CPU parity generator output <NUM>, the memory parity generator output <NUM>, a part of the CPU <NUM> that is external to the parity checker <NUM>, and the comparator <NUM>. The interface <NUM> is to take the CPU parity generator output <NUM> and the memory parity generator output <NUM> as inputs and send the parity values corresponding to the two parity generators to the comparator <NUM>. In other implementations, the interface <NUM> may receive the address information as well as the parity bit from the CPU parity generator <NUM> and the memory parity generator <NUM>. In the previously mentioned implementation, the interface <NUM> may separate the parity bit from the address information for the input that is received from the CPU parity generator <NUM> and for the input that is received from the memory parity generator <NUM>. The coupling between different components listed above can be either wired or wireless depending on the application.

In the illustrated example of <FIG>, the comparator <NUM> is coupled to the interface <NUM> and the fault generator <NUM>. The comparator <NUM> may be implemented as hardware and/or software. In a hardware implementation, XOR logic gates may be used to compare two or more parity bits and generate a result and send that information to the fault generator <NUM>. In a software implementation of the comparator <NUM>, a set of Boolean algebra equations may be used to compare at least two parity bits together and then send that result to the fault generator <NUM>. The coupling between different components listed above can be either wired or wireless depending on the application.

In the illustrated example, the fault generator <NUM> is coupled to the comparator <NUM> and the interface <NUM>. The fault generator <NUM> may be implemented as hardware or in software. As a hardware implementation, the fault generator <NUM> may be a set of logic gates that generate a high-level or low-level signal to be sent to the interface <NUM>. When implemented in software, the fault generator <NUM> may be an else/if statement that is subject to the output of the comparator <NUM>. The output from the fault generator <NUM> is to be sent to the interface <NUM> so that the interface <NUM> may communicate to a part of the CPU <NUM> that is external to the parity checker <NUM>. The coupling between different components listed above can be either wired or wireless depending on the application.

The CPU parity generator <NUM>, the memory parity generator <NUM>, and the parity checker <NUM> allow for the greatest coverage for word-line and bit-line faults while allowing fault detection during the runtime of an application (e.g. used during runtime), whereas previous solutions could only be implemented during the start-up or shutdown of an application due to the destructive nature of prior solutions. Previous solutions are destructive because the memory must be disabled from functional use in order for the previous solution to carry out a full test uninterrupted. This significantly affects system performance because the memory that is being tested is not available for a substantial amount of time. Conversely, when using the CPU parity generator <NUM>, the memory parity generator <NUM> and the parity checker <NUM>, the memory <NUM> is fully functional while monitoring for faults and system performance is not impaired as it is by the previous solutions. The CPU parity generator <NUM>, the memory parity generator <NUM>, and the parity checker <NUM> provide adaptive, on-the-fly feedback for address information to the CPU <NUM>. The CPU parity generator <NUM>, the memory parity generator <NUM>, and the parity checker <NUM> improve the efficiency of using a computing device by closing the loop between address information generation in the CPU <NUM> and address information use in the memory <NUM> of a processing system. This allows for increased protection for faults that may occur between the initial generation of address information in the CPU <NUM> and the decoding of that address information into specific word-line enable values and bit-line enable values in the memory <NUM>.

While an example manner of implementing the fault detection system <NUM> of <FIG> is illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example CPU parity generator <NUM>, the example memory parity generator <NUM>, the example parity checker <NUM>, and/or, more generally, the example the fault detection system <NUM> of <FIG> may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example CPU parity generator <NUM>, the example memory parity generator <NUM>, the example parity checker <NUM>, and/or, more generally, the example fault detection system <NUM> could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example CPU parity generator <NUM>, the example memory parity generator <NUM>, the example parity checker <NUM>, and/or the example fault detection system <NUM> is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the example fault detection system <NUM> of <FIG> may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase "in communication," including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

A flowchart representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the fault detection system of <FIG> is shown in <FIG>. The machine readable instructions may be an executable program or portion of an executable program for execution by a computer processor such as the processor <NUM> shown in the example processor platform <NUM> discussed below in connection with <FIG>. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor <NUM>, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowchart illustrated in <FIG>, many other methods of implementing the example fault detection system <NUM> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

As mentioned above, the example processes of <FIG>, <FIG> may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

As used herein in the context of describing structures, components, items, objects and/or things, the phrase "at least one of A and B" is intended to refer to implementations including any of (<NUM>) at least one A, (<NUM>) at least one B, and (<NUM>) at least one of A and at least one of B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase "at least one of A and B" is intended to refer to implementations including any of (<NUM>) at least A, (<NUM>) at least B, and (<NUM>) at least A and at least B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase "at least one of A or B" is intended to refer to implementations including any of (<NUM>) at least A, (<NUM>) at least B, and (<NUM>) at least A and at least B.

The program of <FIG> shows the process <NUM> to carry out the fault detection system <NUM> of <FIG>. The process <NUM> includes the block <NUM> which is the start of the process <NUM>. The block <NUM> is the block that may instruct the processor to generate a first parity. The process <NUM> may correspond to the example CPU parity generator <NUM> of <FIG>. At block <NUM>, the CPU parity generator <NUM> is to generate the first parity bit which is associated with a first address information. The first address information is associated with the data operands (e.g. based on data operands) in the CPU <NUM> of <FIG>. The first address information is sent to the memory <NUM> by the write address bus <NUM>. The first address information may be a desired location in which the data on the write data bus <NUM> is to be stored in the memory <NUM>.

The process <NUM> includes block <NUM> which is the block that instructs the processor to decode the first address information into word-line enable values and bit-line enable values. These word-line enable values and bit-line enable values correspond to the word-lines <NUM> and bit-lines <NUM> of the memory <NUM> of <FIG>. Block <NUM> may correspond to the example hardware implementation of <FIG>, where block <NUM> may be carried out in hardware as the address decoder <NUM>.

The process <NUM> includes block <NUM>. Block <NUM> is the block that instructs the processor to store data in a memory storage array. The memory storage array may correspond to the memory storage array <NUM> of <FIG> and the data may correspond to the data on the write data bus <NUM> of <FIG>.

The process <NUM> further includes block <NUM>. Block <NUM> is the block that instructs the processor to re-encode the word-line enable values and bit-line enable values into a second address information. This second address information corresponds to the word-line enable values and the bit-line enable values on the word-lines <NUM> and bit-lines <NUM>. This second address information is an actual location where data is stored in a memory storage array. Block <NUM> may correspond to the example hardware implementation of <FIG>, where block <NUM> is implemented as the example address encoder <NUM>. The memory storage array where data is stored may correspond to the memory storage array <NUM> of <FIG>.

The process <NUM> includes block <NUM> which is the block that instructs the processor to generate a second parity bit based off the second address information. This parity bit corresponds to the word-line enable values and bit-line enable values on the word-lines <NUM> and bit-lines <NUM>. Block <NUM> may correspond to the example memory parity generator <NUM> of the example memory <NUM> of <FIG>.

The process <NUM> also includes block <NUM> which is the block that instructs the processor to compare the first parity bit which corresponds to the first address information and the second parity bit which corresponds to the second address information. Block <NUM> may correspond the example parity checker <NUM> of <FIG>.

The process of <FIG> shows the sub-process <NUM> which may be used to implement the block <NUM> of the process <NUM> shown in <FIG>. The sub-process <NUM> is shown in an example hardware implementation in <FIG> by the CPU parity generator <NUM> which is shown in detail in <FIG>. The sub-process <NUM> is to instruct the processor to generate a parity bit based off of a first address information in the CPU <NUM>. The first address information corresponds to data operands in the CPU <NUM> that are used by the address generation unit <NUM> shown in <FIG>.

The sub-process <NUM> begins at the block <NUM> which specifies that the first address information is received from the write address bus before data is stored in the memory storage array. The memory storage array may correspond to the memory storage array <NUM> of the memory <NUM> in the example fault detection system <NUM> of <FIG>. The first address information may be on the write address bus <NUM>. Block <NUM> may be carried out by the interface <NUM> of the example CPU parity generator <NUM> shown in <FIG>.

The next block in the sub-process <NUM> is block <NUM> which is the block that instructs the interface <NUM> of the example CPU parity generator <NUM> to send the address information to the logical determiner <NUM> of <FIG>. Block <NUM> may represent the coupling between the interface <NUM> and the logical determiner <NUM> of <FIG>.

Next in the sub-process <NUM> is block <NUM> which is the block that determines a parity bit or parity bits for an address information that is sent to it. The block <NUM> may be carried out in hardware as the logical determine <NUM> in the CPU parity generator <NUM> of <FIG>. The number of parity bits that are determined is based on the size of the address information. Parity bits are typically determined for each set of <NUM> bits of information. For example, the data input into the CPU parity generator <NUM> is to be separated by the interface <NUM> into <NUM>-bit segments for use by the logical determiner <NUM>. For a <NUM>-bit address information, the logical determiner <NUM> would determine <NUM> parity bits.

Next in the sub-process <NUM> is the block <NUM> which is the block that sends the determined parity bits to the parity checker. The parity checker may correspond to the parity checker <NUM> of the CPU <NUM> of <FIG>. The block <NUM> may be represented in hardware as the CPU parity generator output <NUM>. Next in the sub-process <NUM> is the block <NUM> which is the block that instructs the sub-process <NUM> to return to the process <NUM> of <FIG>.

The process of <FIG> shows the sub-process <NUM> which may be used to implement the block <NUM> of process <NUM> shown in <FIG>. The sub-process <NUM> is shown in an example hardware implementation in <FIG> by the memory parity generator <NUM> which is shown in detail in <FIG>. The sub-process <NUM> may instruct the processor to generate a parity bit based off of a second address information in the memory <NUM>. The second address information corresponds to word-line enable values and bit-line enable values that correspond to the word-lines <NUM> and the bit-lines <NUM> in the memory <NUM> shown in <FIG>.

The sub-process <NUM> begins at the block <NUM> which specifies that the second address information is received on the address check bus after the data is stored in the memory storage array. The address check bus may correspond to the address check bus <NUM> of <FIG>. The memory storage array may correspond to the memory storage array <NUM> of the memory <NUM> of <FIG>. Block <NUM> may be carried out by the interface <NUM> of the example memory parity generator <NUM> shown in <FIG>.

The next block in the sub-process <NUM> is block <NUM> which is the block that instructs the interface <NUM> of the example memory parity generator <NUM> to send the address information to the logical determiner <NUM> of <FIG>. Block <NUM> may represent the coupling between the interface <NUM> and the logical determiner <NUM> of <FIG>.

Next in the sub-process <NUM> is block <NUM> which is the block that determines a parity bit or parity bits for an address information that is sent to it. The block <NUM> may be carried out in hardware as the logical determiner <NUM> in the memory parity generator <NUM> of <FIG>. The number of parity bits that are determined is based on the size of the address information. Parity bits are typically determined for each set of <NUM> bits of information. For example, the data input into the memory parity generator <NUM> is to be separated by the interface <NUM> into <NUM>-bit segments for use by the logical determiner <NUM>. For a <NUM>-bit address information, the logical determiner <NUM> would determine <NUM> parity bits.

Next in the sub-process <NUM> is the block <NUM> which is the block that sends the determined parity bits to the parity checker. The parity checker may correspond to the parity checker <NUM> of the CPU <NUM> of <FIG>. The block <NUM> may be represented in hardware as the memory parity generator output <NUM>. Next in the sub-process <NUM> is the block <NUM> which is the block that instructs the sub-process <NUM> to return to the process <NUM> of <FIG>.

The process of <FIG> shows the sub-process <NUM> which may be used to implement the block <NUM> of process <NUM> shown in <FIG>. The sub-process <NUM> is shown in an example hardware implementation in <FIG> by the parity checker <NUM> which is shown in detail in <FIG>. The sub-process <NUM> may instruct the processor to compare two or more parity bits.

The sub-process <NUM> begins at the block <NUM> which specifies that the processor receives the first parity bit(s) from the first parity generator. The first parity generator may correspond to the CPU parity generator <NUM> shown in <FIG>. The next block in the sub-process <NUM> is the block <NUM> which specifies that the processor receives the second parity bit(s) from the second parity generator. The second parity generator may correspond to the memory parity generator <NUM> shown in <FIG>. An example implementation of the sub-process <NUM> is shown in <FIG>, wherein blocks <NUM> and <NUM> of the sub-process <NUM> may be carried out by the interface <NUM>.

Next in the sub-process <NUM> is block <NUM> which is the block that compares the two or more parity bits and specifies whether or not the two or more parity bits are different. The block <NUM> of the sub-process <NUM> may be implemented as the comparator <NUM> in the example parity checker <NUM> of <FIG>. If the block <NUM> compares the two or more parity bits and specifies that the two or more parity bits are different, then the sub-process <NUM> moves onto block <NUM>, if not, the sub-process <NUM> moves onto block <NUM>.

In the sub-process <NUM>, the block <NUM> is the block that generates a fault which specifies that the two or more parity bits are different. The fault denotes that the first address information is different from the second address information. The first address information corresponding to data operands in the CPU <NUM> that are used by the address generation unit <NUM>. The second address information corresponding to the set of word-line enable values and the set of bit-line enable values and the actual location where the data is stored. Block <NUM> may be implemented as the fault generator <NUM> of <FIG>.

The sub-process <NUM> then passes from block <NUM> to block <NUM>. Block <NUM> is the block that sends the result of comparing the two or more parity bits to a part of the processor that is external from the parity checker. To accomplish this, the result may first be sent to the interface <NUM>. The interface <NUM> may then send the result of the comparison to a part of the CPU <NUM> that is external to the parity checker <NUM>. From the value of this result, the CPU <NUM> may determine whether or not to enact safety protocols for faults. The safety protocols for faults are to mitigate the effects of a fault and to prevent unsafe conditions in an application. The next block in sub-process <NUM> is the block <NUM> which is the block that instructs the sub-process <NUM> to return to the process <NUM> of <FIG>.

<FIG> is a block diagram of an example processor platform <NUM> structured to execute the instructions of <FIG>, <FIG> to implement the system of <FIG>. The processor platform <NUM> can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a headset or other wearable device, or any other type of computing device.

For example, the processor <NUM> can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor implements the CPU parity generator <NUM> and the parity checker <NUM>.

In this example, the volatile memory <NUM> includes the memory parity generator <NUM>.

The machine executable instructions <NUM> of <FIG>, and <FIG> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD.

Claim 1:
A system comprising:
a first parity generator to generate a first parity based on a first address information used in a processor and corresponding to a desired location to store data in a memory storage array;
a second parity generator to generate a second parity based on a second address information used in the memory and corresponding to an actual location where data is stored in the memory storage array; and
a parity checker to compare the first parity and the second parity to detect a fault;
wherein the first address information corresponds to data operands in the processor and the second address information corresponds to a set of word-line enable values and a set of bit-line enable values.