In many applications it is important that a proper command is generated in response to command inputs. Therefore, various ways to check that a given command was generated correctly in response to command inputs have been developed. One way to help ensure proper commands are generated is to use hardware command monitors that can be used to check the output of a logic device that generates the commands. These self-checking architectures can be implemented in several ways. In one embodiment, two processing lanes are provided. Each processing lane includes a command generating logic device and a comparison logic device. The command generating device in each processing lane receives the same command requests and generates a command from those requests. The command generated by each command logic device is sent to the comparison logic device in the opposite processing lane, to verify the generated command is correct. If the output of both processing lanes is verified as correct, the commands can be used. If the commands do not match, the commands are discarded.
Command monitoring is implemented in many fields, including the avionics field. For example, a pilot may wish to bank the plane a certain amount and control the yoke of the aircraft a certain amount. The commands generated by the pilot's maneuvering of the yoke can be sent to a flight control system that will monitor the process to ensure the commands generated are correct. In some cases, such as in fly-by-wire systems, the commands may be generated by the flight control system. Therefore, it is desirable to verify the command generation process.
As command generating systems become more sophisticated, they may require memory, such as random access memory (RAM), to store data to and retrieve data from while generating commands. The self-checking hardware thus becomes dependent on the proper functioning of the RAM. It then becomes necessary to ensure the RAM is operating properly. One potential failure mode for RAM particularly troubling in self-checking architectures is a latent failure whereby specific bits in the memory cannot assume a specific state when required. The redundant nature of self-checking architectures makes it highly probable that faults are detected when they occur. However a latent failure can occur in RAM that usually receives the same data, such as a RAM where certain bits always take on the value of “0”, except upon the occurrence of a rare operational condition or mode when the value needs to be a “1”. If a failure has occurred in the memory such that the bit can't change from a “0”, the fault may go unnoticed until that condition occurs. Thus, the latent memory failure renders the command generating system unavailable, potentially at a time most critical.
One way to detect latent RAM failure is through the use of built in testing (BIT) for memory. These tests typically read and write specific patterns to the memory to ensure each memory bit is operating properly. However, to develop BIT for memory in hardware based comparison systems that do not contain microprocessors can be complex.
Accordingly, it is desired to provide a method and apparatus for latent fault memory scrub in memory intensive computer hardware. Furthermore, the desirable features and characteristics of the present invention will be apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.
USPTO Backgrounds
USPTO Backgrounds