Debug Method To Efficiently Trigger A Processor/Memory Bus After Data Corruption Or Other Errors In A Computer System.
Original Publication Date: 2000-Mar-01
Included in the Prior Art Database: 2003-Jun-19
A method was needed to enable hardware debugging of a computer system immediately after a data miscompare or hardware/software error condition occurred within a program. (i.e. memory exerciser) The characteristics of this method should allow a trigger to an external hardware test equipment in a very short time span in terms of CPU cycles. If the data miscompare (or error condition) and the trigger were separated by too many cycles then the event couldn't be captured within today's logic analyzers that have about a 2MB state stack. This method typically results in 100 to 1000 CPU cycles between a data miscompare and the trigger which allows easy backtracking within a logic analyzer to the failed CPU instruction. The program must include a variable that is ideally the size of the processor-memory bus. In today's Intel processors this is 64 bits. This variable must be allocated at program start time to eliminate any memory allocation CPU cycles between the data miscompare operation and the trigger. At start time this variable should also be initialized to some value (i.e. zero or user trigger). Immediately after a data miscompare is detected this variable is written with a new pattern. The actual write operation should be to the variable should be directly to the variable to minimize CPU instructions for pointer de-referencing. This pattern can then be used as a unique data pattern trigger for a hardware tool like a HP processor/memory preprocessor. Even though the primary use of this type of trigger is to aid hardware debugging due to data corruption it can be used to signal any hardware or software condition that can be evaluated. For instance, a hardware bit could be tested to see if it's false so that a trigger is set. Alternately, a software API could be evaluated for a condition and the trigger sent if it's false. Crude Version of Method A crude version of this trigger counts on the size of the processors caches and the amount of data written to those caches between the data miscompare and the trigger. For instance, a uniprocessor machine containing a processor with a 256K L2 cache can only hold about 256K worth of data. Today's processors typically flush the least recently used caches. This version of the method does the following steps. It allocates and initializes the trigger variable which essentially loads a cache line or more. Then if this cache line is moved out to main memory because it's old and must be moved out due to processor cache capacity then any new reference to the variable will cause it to move back across the processor-memory bus. In a simple case you can cause this processor to exceed it's cache by writing a buffer that is larger than 256K. When the data moves back across the bus then that can be used as the trigger mechanism for external hardware test tools like a processor/memory preprocessor and logic analyzer.