Abstract:
A method for diagnosing hardware failures in a data processing system includes a configuring a portion of a programmable logic device to create a state machine. The state machine tests a communication bus and a plurality of component devices connected by the communication bus and identifies the test failures. The state machine communicates the test information to external test equipment. The communication bus is used in the operation of the data processing system and the testing includes tests at full clock speed of the data processing system.

Description:
BACKGROUND 
     The present invention relates to diagnosing failures in data processing systems. In particular, the invention relates to built-in, self-test capabilities for data processing system hardware. 
     Built-in, self-test capabilities have become essential as the design of data processing systems has become more complex. Historically, with simple systems made up of relatively few individual components, each of minimal complexity, testing a data processing system to find a failed component was a simple matter of testing across each component. As system complexity increased with greater levels of integration, access to test points across each component disappeared and the number of components to test to diagnose a data processing system problem skyrocketed. 
     Even in systems where test points remain, today&#39;s high-speed, high-performance data processing systems are difficult to test using an external logic analyzer because of the long lead lines from analyzer to circuit. The long lead lines make accurate testing, at full system clock speed, almost impossible. This is problematic, because some data processing system problems only appear when tested at full system clock speed. In addition, although some useful test information can be obtained with external testing, this becomes very difficult once a data processing system is in the field. Units must be disassembled and protective covers removed to gain access to the test points, increasing the likelihood of inducing further damage to the data processing system. The solution has been to build in an automated capability, such that the system could test itself and report failures. 
     Built-in, self-test designs generally fall into one of two approaches: a software-based capability or a JTAG boundary scan capability. Both approaches are useful, but have serious drawbacks. Software-based approaches use code stored in the memory used by the central processing unit (CPU) and the CPU itself to test system components and identify and report failures. The major drawback is that if the CPU is not working correctly and is itself part of the problem, the hardware diagnosis process stops or becomes severely limited. In addition, the CPU can not thoroughly test itself or its associated memory because it requires those resources to run the test software. 
     Boundary scan approaches avoid the working CPU requirement of the software approach by creating a separate test bus to circumvent the communication bus used within the data processing system. Boundary scan is often referred to by the group that began developing a standard for using boundary scans, Joint Test Action Group (JTAG). JTAG is the common name for the IEEE 1149.1 standard, which defines a test bus and defines test ports that components must have to interface with the test bus. As typically implemented, a programmable logic device with the built-in, self-test JTAG firmware is installed in the data processing system and uses the test bus to test some of the data processing system components. Only components designed to interface with the test bus can be tested by the boundary scan method. Such components are commonly referred to JTAG enabled. This is a major limitation on the JTAG boundary scan approach. Many components in a data processing system are not JTAG enabled and, as a result, are not tested by the built-in test, requiring a return to external logic analyzer testing and its attendant problems (if test points are even available). This severely limits the usefulness of the JTAG boundary scan approach in diagnosing data processing system failures. In addition, the JTAG boundary scan approach does not test the communication bus directly, but only through JTAG enabled components, limiting coverage of communication bus testing. For example, a continuity failure at a component not JTAG enabled would not be detected by the boundary scan. 
     Finally, the JTAG boundary scan test often is not able to operate at full clock speed of the data processing system. As mentioned above, some data processing system problems only appear when tested at full system clock speed. Using the JTAG boundary scan approach makes detection of such high-speed, high-performance system failures impossible. 
     SUMMARY 
     One embodiment of the present invention includes a method for diagnosing hardware failures in a data processing system including a programmable logic device. A portion of the programmable logic device is configured to create a state machine. The state machine tests a communication bus and a plurality of component devices connected by the communication bus and identifies the test failures. The state machine communicates the test information to external test equipment. The communication bus is used in the operation of the data processing system and the testing includes tests at full clock speed of the data processing system. 
     Another embodiment of the present invention, a system for diagnosing hardware failures in a data processing system, includes a plurality of component devices and a programmable logic device connected by a communication bus. A portion of the programmable logic device is configured to create a state machine for testing and identifying hardware failures and to produce test failure information. A test interface is connected to the programmable logic device for communicating test failure information from the state machine to external test equipment. The communication bus is used for operation of the data processing system and for testing and identifying hardware failures by the state machine. The state machine testing includes tests at full clock speed of the data processing system. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of control system which utilizes the present invention. 
         FIG. 2  is a block diagram of a data processing system with a built-in, self-test capability for diagnosing hardware failures of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram of control system which utilizes the present invention.  FIG. 1  shows a control system  10 , including a sensor  12 , an actuator  14 , and a data processing system  20  of the present invention. Sensor  12  is any type of sensor producing an analog or digital output signal in response to a condition to be sensed, including, for example, a linear position sensor, a rotary position sensor, and a temperature sensor. Actuator  14  is any type of electrical component producing an effect based on an input signal, including, for example, a motor, a valve, or piezoelectric device. 
     Sensor  12  and actuator  14  are both electrically connected to data processing system  20 . In operation, sensor  12  produces a signal in response to the condition to be sensed and sends the information to data processing system  20 . Data processing system  20  processes the data represented by the input signal and generates a specific output signal. Data processing system  20  sends the output signal to actuator  14 , which responds with the appropriate effect on the condition being sensed. The control system  10  responds to changes in the condition to be controlled and makes automatic adjustments to keep the condition to be controlled within a desired range. In the field, control systems  10  operate in a variety of locations under a variety of conditions. Locations are often difficult to access and ambient conditions are often hazardous to the internal components of sensor  12 , actuator  14  and data processing system  20 . 
       FIG. 2 . is a block diagram of the data processing system  20  with built-in, self-test capability for diagnosing hardware failures of the present invention. As shown in  FIG. 2 , data processing system  20  component devices include digital signal processor (DSP)  22 , oscillator  24 , volatile memory  26 , non-volatile memory  28 , programmable logic device (PLD)  30 , communication bus  32 , and external interface  34 . PLD  30  includes IO logic  36  and state machine  38 . Volatile memory  26  is any of the various memory storage devices that lose stored data values if power is no longer applied, for example, dynamic random access memory and static random access memory. Non-volatile memory  28  is any of the various memory storage devices that maintain stored data values even if power is no longer applied, for example, electrically erasable programmable read-only memory (EEPROM) and flash memory. PLD  30  is any of the larger programmable logic arrays, for example field programmable gate array (FPGA) and complex programmable logic device (CPLD). Communication bus  32  is any of the standard local computer bus protocols, for example, Peripheral Component Interconnect (PCI), Low-Voltage Differential Signaling (LVDS), and VERSAmodular Eurocard (VME). 
     Oscillator  24  is connected to DSP  22 . DSP  22 , volatile memory  26 , non-volatile memory  28 , and PLD  30  connect to communication bus  32 . PLD  30  is also connected to external interface  34 . Connections to external devices, such as sensor  12 , actuator  14  (shown in  FIG. 1 ), and external test equipment, are made through external interface  34 . 
     The built-in, self-test capability of the present invention is initiated when PLD  30  is configured through external interface  34  with logic instructions necessary to test components attached to communication bus  32 . This creates state machine  38 . The proportion of PLD  30  occupied by state machine  38  will vary depending on the complexity of data processing system  20 . This firmware programming is ideally completed at an early stage in the manufacture of data processing system  20  to take full advantage of the self-test capability, but firmware programming of state machine  38  can also be installed and updated throughout the life of data processing system  20 . 
     Once configured, a signal from the external test equipment through external interface  34  to state machine  38  triggers the state machine  38  to test data processing system  20 . State machine  38  tests include a test sweep employing input/output test patterns directed toward external interface  34  to verify the health of external interface  34 . State machine  38  also tests I/O logic  36  by writing a value to all memory locations comprising I/O logic  36  and then reading back a value from each memory location. Discrepancies between the two values for each location are noted as errors and information on the test failure location and test failure mode of the errors in I/O logic  36  are reported by state machine  38  to the external test equipment through external interface  34 . State machine  38  checks the health of communication bus  32  by checking for shorts or opens for every address of communication bus  32 . Volatile memory  26  and non-volatile memory  38  are tested by state machine  38  writing to and reading from each memory location over communication bus  32 , flagging and reporting errors as described above for I/O logic  36 . State machine  38  tests DSP  22  and oscillator  24  over communication bus  32  using various modes and test patterns to gauge the health of DSP  22  and oscillator  24 , reporting details of any failures, including test failure location and test failure mode, to the external test equipment through external interface  34 . 
     In the present invention, state machine  38  is able to test all component devices of data processing system  20  connected to communication bus  32  quickly and efficiently. No separate test bus is required, in contrast to JTAG boundary scan testing. Because the communication bus is used, not a separate test bus, all components can be tested, not just those that are JTAG enabled. For reasons of cost, performance, and availability, many component devices are not JTAG enabled. With the present invention, such component devices are not excluded from the built-in test. The result is a more complete, effective diagnosis of hardware failures. 
     The present invention also permits testing of component devices at full clock speed of the data processing system  20 . Oscillator  24  provides the clock speed for data processing system  20 . Because the state machine  38  tests DSP  22  and oscillator  24  over communication bus  32 , communication bus  32  and the component devices connected to communication bus  32  can be tested at full clock speed. In contrast, JTAG boundary scan is not able to operate at full clock speed for many of today&#39;s high-speed, high-performance data processing systems. With the present invention, data processing system hardware failures that only appear at full system clock speed are not excluded from the built-in test. 
     The present invention also overcomes a major drawback of a software-based approach to implementing built-in self-test. Because all testing is driven by state machine  38 , proper operation of DSP  22  is not necessary to evaluate the health of the hardware for data processing system  20 . A great deal of hardware diagnostics on component devices and on DSP  22  itself can be done even if DSP  22  is not working correctly. This saves a great deal of time in troubleshooting because multiple failures can be detected simultaneously, not just after a failed DSP is replaced. 
     Data processing system  20  with a built-in self-test capability for diagnosing hardware failure of the present invention permits much more complete troubleshooting of hardware failures through external interface  34 . Everything tested with a JTAG boundary scan approach or a software-based approach is tested with the present invention, and much more, as described above. As a result, field testing can be done quickly, efficiently and completely through test interface  34  with no need to remove protective covers for test purposes. Data processing system  20  is not exposed to potentially damaging activities or hazardous environmental conditions. 
     The form of data processing system  20  will vary depending on the level of integration desired for a particular application. In systems for applications requiring small size, data process system  20  is constructed on a single integrated circuit. In systems for applications of great complexity where size is not an overriding concern, data processing system  20  is constructed over several printed circuit boards, connected by communication bus  32  which necessarily extends to each board. In systems with intermediate requirements, data processing system  20  is constructed on a single printed circuit board. Also, although  FIG. 2  illustrates only a single unit of each of various types of component device (DSP, PLD, oscillator, etc.), the present invention contemplates multiple quantities of each type of component device as necessary to meet the performance requirements of data processing system  20 . 
     While the invention has been described with reference to an exemplary embodiment(s), it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment(s) disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.