WO1996038788A2

WO1996038788A2 - Internal state dump mechanism for saving processor values during system testing

Info

Publication number: WO1996038788A2
Application number: PCT/US1996/008129
Authority: WO
Inventors: Timothy A. Hostetter; Michael T. Wisor
Original assignee: Advanced Micro Devices, Inc.
Priority date: 1995-05-31
Filing date: 1996-05-31
Publication date: 1996-12-05
Also published as: WO1996038788A3

Abstract

The present invention discloses a system and method for saving the internal state values of a central processing unit (CPU) even in situations where the processor fails. The processor preferably includes a mechanism for triggering a CPU internal state dump when the processor has become hung. In response, the CPU dumps its internal state values into a reserved space in system memory. As part of that process, the CPU also provides a signature to the beginning of the state dump to validate the contents of that memory block as CPU state information. After the internal values are dumped to memory, the CPU preferably undergoes a soft reset, during which refresh continues to the system DRAM memory, thus preserving the data in the DRAM circuits. When coming out of reset, the CPU flushes any dirty data in cache memory to the system memory to prevent coherency problems and continues the DRAM refresh. The CPU checks for a valid signature in the reserved portion of DRAM, and if no signature is present, continues with a normal boot sequence. If the signature is present, the boot is aborted, and the system is set up for transferring the state information and other memory contents to an external processor for analysis.

Description

TITLE: INTERNAL STATE DUMP MECHANISM FOR SAVING

PROCESSOR VALUES DURING SYSTEM TESTING

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to the design and development of new microprocessors. More particularly, the present invention relates to the testing of integrated processors, and the saving and retrieval of internal CPU (central processing unit) values when the processor fails.

2. Description of the Relevant Art

Microprocessors (or simply processors) typically comprise the "brains" of a personal computer (PC) system. While PC's can be provided with increased capabilities by adding or upgrading peripheral features, to substantially increase PC performance it is necessary to upgrade the microprocessor. The development of new and improved processors, however, is an extremely costly venture. While modifications may be made continuously to an existing processor product line, the introduction of a new processor is a major enterprise.

New processor designs typically are produced in iterative steps. Microprocessor prototypes are fabricated on silicon chips, and then are tested using various techniques to determine if the processor design, as fabricated, will perform satisfactorily. As errors are detected, the microprocessor design is modified and new prototypes are produced embodying the modified design. This seemingly continuous process of designing, fabricating and testing a processor design is referred to as "debugging."

Microprocessors are tested in many ways. One of the preferred methods of testing a microprocessor design is to place the microprocessor in a system environment that simulates the intended use of the processor. For example, it is desirable to test a processor designed to function as the CPU of a personal computer (PC) system in a PC environment. To simulate the PC environment, the processor is connected to system memory and various peripheral components that typically are found in a computer system. The processor then is connected to a host processor system which tests the processor by performing predetermined tests on the processor. The host processor system may include logic analyzer capabilities to monitor the external bus states and timing information of the processor.

An example of a simplified testing environment is shown in Figure 1 A, which includes the device under test 10 (preferably a processor) connected to a system random access memory (RAM) 25 and an input/output device 17. The processor 10 connects electrically to the input/output device 17 and to the system memory or RAM 25 through appropriate buses 12. 14, respectively, in accordance with conventional techniques. In addition, the processor 10 connects electrically to a host processor 20 through a suitable serial or parallel bus 15. In appropriate circumstances, the input/output device 17 and host processor could reside on the same bus. As one skilled in the an will understand, various changes can be made to this base system by adding additional peripheral devices, or the input/output device 17 could be removed so that the only external accesses to the processor originate from the host processor 20.

Recently, there has developed a trend in the computer industry to integrate components that were previously provided separately onto one or more integrated circuits. An example of such a computer system is shown, for example in Figure I B. Figure IB is a block diagram of a computer system 30 including a microprocessor (CPU) 35, a CPU local bus 34 coupled to the CPU 35, a memory controller 37 and a local bus peripheral device 38 coupled to the CPU local bus 34. In contrast to earlier processor designs, each of these components may be fabricated together as part of an integrated processor.

Such an integrated processor design poses special problems during debug because of the many internal connections and registers of the CPU 35 that are not accessible externally. As a result, the values of these registers and internal connections cannot be directly monitored by the host processor 20 shown in Figure 1 , unless a special request is made to the CPU 35 to download its internal contents. The problem with this method is that it is particularly desirable during testing to determine the internal contents of the CPU 35 when it fails or hangs. When an integrated processor fails, it usually is impossible to retrieve these internal values, and thus valuable diagnostic information is lost which could greatly reduce the amount of time required to debug the processor design.

It would be advantageous if the internal contents of the CPU could be saved and retrieved even when the integrated processor fails. While the advantages of such a mechanism are apparent to one skilled in the art, to date no one has developed a method to consistently obtain this invaluable diagnostic information.

SUMMARY OF THE INVENTION

The probtems outlined above are in large part solved by the teachings of the present invention. The present invention incorporates a technique for dumping the internal state information of a CPU into system memory when the processor fails during system testing. According to the preferred embodiment, after determining that it is in a hung state, and/or after receiving an appropriate external command, the CPU dumps the contents of its internal state machines and registers into dynamic random access memory (DRAM), where the internal CPU data is stored. As part of the dump to DRAM, the CPU writes a state dump signature into a special block of DRAM to identify that portion of DRAM as containing valid state dump information.

After being reset, the CPU scans the signature block for the presence of the signature. If no signature is present, the CPU performs a normal boot sequence. If, conversely, a valid signature is present in the signature block, the CPU transmits the validated state dump data in DRAM to the host processor for processing and analysis into a meaningful format for the debug engineers and designers. During each reset sequence, the CPU reserves a block of DRAM for storing only internal CPU state information. In addition, the boot code of the CPU is specially modified to insure that the reserved section of DRAM is not tested by the CPU until the signature block is examined to determine if state information is present in the DRAM. Because the CPU state information is stored in DRAM in the preferred embodiment, the system also must be configured to allow for continuous DRAM refresh to prevent the data in DRAM from being lost.

Additionally, depending upon the configuration of the system and the manner in which reset is initiated, the CPU must take appropriate measures to prevent cache coherency problems with DRAM. When a cache memory is present in the system and is enabled, the CPU must either flush the cache memory back into DRAM before resetting or immediately after resetting, to avoid problems of cache coherency.

In an exemplary embodiment of the present invention, the processor includes a CPU core connected to a memory control unit and to a bus interface unit via a CPU local bus. The processor also includes a cache memory and a cache controller for controlling the operation of the cache memory. The memory control unit connects to DRAM and to a read only memory (ROM), in which the BIOS code is stored. The processor connects through the bus interface unit to a host processor and to an input/output device.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which:

Figure 1 A is a block diagram representation of a prior art test environment for a data processor;

Figure 1 B is an exemplary block diagram of an integrated processor design;

Figure 2 is a block diagram illustration depicting an exemplary embodiment of an integrated processor undergoing testing in a system environment;

Figure 3 is a block diagram depicting the portions of DRAM reserved for use in the present invention;

Figure 4 is a more detailed illustration of the portion of DRAM reserved for storing CPU internal state information in accordance with the principles of the present invention; and

Figure 5 is a flow chart showing the general methodology by which the CPU implements the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to iimit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE INVENTION

The present invention generally relates to an integrated processor design which is being tested to determine if it will perform satisfactorily. The present invention can also be used to retrieve diagnostic information from any failed processor, whether the processor is in the test phase, or is already operational.

In the preferred embodiment of Figure 2, the device under test comprises a data processor 100, which is connected via a bus 1 15 to a host processor 120 for serial transmission of data between the host processor and data processor 100. As an alternative, the host processor 120 may be connected to the data processor 100 over a parallel bus, if so desired. The data processor 100 also preferably connects to a system bus 1 12, which may comprise the main electrical network for connecting various components in a computer system. The system bus 1 12 may comprise a PCI (peripheral component interconnect )bus, an ISA (industry standard architecture) bus, an EISA (extended industry standard architecture) bus, or any other suitable bus.

As shown in Figure 2, an input/output device 170 preferably connects to the system bus 1 12. Other peripheral devices (not shown), such as an integrated hard drive for example, may connect to the system bus 1 12. In the preferred embodiment, commands may be transmitted from a user through the input/output device 145. which may for example comprise a keyboard and keyboard controller. As a result, in the preferred embodiment, commands may be issued to the integrated processor 100 either through the host processor 120 or through the input/output device, using an appropriate operating system, such as DOS.

Referring still to Figure 2, the data processor 100 preferably comprises an integrated processor, in accordance with recent trends to integrate components that were previously provided separately onto one or more integrated circuits. The integrated processor 100 preferably includes a central processing unit (CPU) core 1 10, a CPU local bus 165 coupled to the CPU core 1 10, a bus interface unit 155 and a memory control unit 140, both of which are coupled to the CPU local bus 165. In accordance with the exemplary embodiment of Figure 2, the integrated processor also includes a cache memory unit 175 and a cache controller 180, connected to the CPU core 1 10 via a cache bus 185. As one skilled in the art will understand, any of the peripheral components of the processor 100, such as cache memory 175, or memory control unit 140, may be located externally from the processor 100. Alternatively, if desired, the cache memory 175 and cache controller 180 may be eliminated entirely from the svstem.

The CPU core 1 10 preferably includes an internal ROM 105 in which the microcode for the CPU is stored. The CPU core 1 10 is illustrative of, for example, a Pentium compatible microprocessor, with reduced instruction set computer (RISC) operations. The CPU local bus 165 is exemplary of a Pentium compatible style local bus. The CPU local bus 165 includes a set of data lines, a set of address lines, and a set of control lines (not shown individually).

According to normal convention, the processor 100 couples to other peripheral computer components through one or more external buses. As shown in Figure 2, the system bus 1 12 couples to the CPU local bus 165 through a suitable bus interface unit 155. The bus interface unit 155 provides a standard interface between the CPU local bus 165 and the system bus 1 12. As such, the bus interface unit 155 orchestrates the transfer of data, address, and control signals between the two buses. The bus interface unit 155 also preferably orchestrates the transfer of signals between the local bus 165 and the serial bus 1 15.

The memory control unit of Figure 2 couples to the CPU local bus 165 and to a memory bus 235 to control memory transactions between system components and system memory 225. The system memory 225 typically includes banks of dynamic random access memory (DRAM) circuits. The DRAM circuits connect to the memory controller 230 via a memory bus 235, comprised of memory address lines, memory data lines, and various control lines. In accordance with the exemplary embodiment of Figure 2, the memory control unit 140 also connects to a read only memory (ROM) device 245 via the memory bus 235. In the embodiment of Figure 2, the ROM device 245 preferably stores the BIOS (basic input/output system) instructions for the computer system. As one skilled in the art will understand, the BIOS ROM 245 may be located elsewhere in the computer system if desired. According to conventional techniques, the BIOS ROM 245 stores the boot code for initializing the computer system.

The DRAM banks, according to normal convention, comprise the working memory of the integrated processor 100. As shown more particularly in Figure 3, a 128Λbyte segment 295 of memory is reserved in DRAM 225 to store the internal state information of the CPU during a state dump. According to conventional techniques, other regions of the DRAM 225 may also be reserved for storage of other data, as shown for purposes of illustration in Figure 3. As shown in the exemplary embodiment of Figure 4, the reserved block 295 of DRAM may be configured in rows and columns. In the embodiment of Figure 4, the rows define lines of memory which are 16 bytes (or 4 doublewords) long. As a result, 8000 lines are required to obtain the 128/±>yte block.

Referring still to Figure 4, the first doubleword in the reserved block 295 of DRAM preferably comprises a signature block. The signature block provides an indication of whether a state dump has occurred to the memory block 295. in accordance with the present invention. If a state dump has occurred, the CPU encodes the signature block with particular information identifying the mechanism by which the state dump was triggered. In the preferred embodiment, the first word of the signature block will identify the processor, and the second word will identify the mechanism by which the state dump was triggered (i.e the FLUSH# signal was asserted when the processor was in a hung state). The signature block therefore provides diagnostic information regarding the triggering of the state dump procedure.

Referring still to Figure 4, the last byte of the reserved block 295 preferably is reserved for a check sum value. According to the preferred embodiment, the CPU preferably sums the binary values stored in the state dump region 295 of DRAM 225, performs a two's complement of that sum, and stores the complemented value in the check sum byte. When the state dump contents later are transmitted to the host processor or other external analyzer, the receiving device preferably checks to insure that it has received a proper transmission by performing its own check sum analysis and comparing the result with the check sum value stored in the check sum byte.

Referring again t«. the exemplary embodiment of Figure 2, a plug-in card 190 may also connect to the peripheral bus 1 12. As one skilled in the art will realize, the components on card 190 may alternatively be included in the system via a hard wire connection to the peripheral bus 190. According to one embodiment of the present invention, the plug-in card 190 preferably includes a read only memory device (ROM), on which a revised microcode patch has been stored, according to the teachings of commonly assigned U.S. Application Serial

No. , (Express Mail No. ), entitled "A System and Method for Patching Microcode

During the Debugging of a Processor", filed concurrently herewith.

During the testing of the integrated processor 100 in the system environment shown in Figure 2, the processor and other system components will fail periodically. If the processor 100 gets "hung," or ceases operating properly, it may become necessary to cycle power to the processor 100, causing the processor to reset. The present invention makes it possible to recover the internal contents of the processor 100 even when it has hung.

The processor 100 constructed in accordance with the preferred embodiment includes a mechanism by which the entire internal state of the CPU 1 10 can be transferred to system memory 225. Some of the various mechanisms that can be used to trigger the state dump of the CPU 1 10 are (1 ) the execution of a special operating code programmed in the microcode ROM 105 when a hung state is detected by the processor; (2) the assertion of a FLUSH# pin on the integrated processor by the host processor 120 or input7output device 145 when the processor is hung; (3) the assertion of a SMI# pin on the integrated processor by the host processor 120 or input/output device 145 when the processor is hung; (4) the assertion of an INTR# pin on the integrated processor by the host processor 120 or input/output device 145 when the processor is hung; or (5) special coding of a hardware configuration register (not shown specifically) in the integrated processor 100, either through a user input from the input/output device 145, or from an automatic routine in the processor based upon the detection of a hung state. Other mechanisms also may be used to cause the CPU to dump its internal contents by appropriately providing microcode in the microcode ROM 105 in the CPU 110, as will be understood by one skilled in the art. As one skilled in the art also will appreciate, the host processor 120 or input/output device 145 can be connected to the integrated processor to provide any one or all of the FLUSH#, SMI# and or INTR# signals.

The above listed mechanisms for triggering a state dump may be implemented through the use of a microcode patch, as detailed in concurrently filed U.S. Application Serial No. , (Express Mail

No. ), entitled "A System and Method for Patching Microcode During the Debugging of a

Processor". As set forth more fully in that application, the microcode ROM 105 may be patched with modified instructions contained in an external ROM located on plug-in card 190. Thus, for example, if the processor 100 detects a hung state in the system, a tag bit can be set in a table in the CPU core 1 10 to indicate that if a particular microcode instruction in ROM 105 is to be read (as may occur for example when the FLUSH#, INTR# or SMI# pin is asserted), the CPU core 1 10 branches to the ROM device on card 190 for that instruction. By modifying the instruction with a command to dump internal state information, the mechanism for triggering the state dump can be implemented.

After the processc r 100 dumps its contents in system memory 225, the state information must be retrieved from memory 225. Because the processor 100 is in a hung state, access to the system memory 225 probably will be impossible. As a result, the processor 100 must first be reset so that the state information may subsequently be recovered from the system memory 225.

The recovery of the state dump information from system memory 225, however, poses special problems and requires a modification of the BIOS code stored in ROM device 245 to insure that the state information in system memory 225 is not lost when the processor 100 is reset. The system memory 225, as noted above, typically is constructed of DRAM circuits. DRAM circuits must be periodically refreshed, or the data stored in the various cells of the DRAM circuits will be lost. The present invention preferably implements a soft reset feature, in which the CPU is reset while refresh is maintained to the DRAM bank 225.

According to the preferred embodiment, the soft reset is triggered by the assertion of an INIT# pin by the operator. For purposes of illustration, the INIT# line is shown as an external connection on the integrated processor 100. Either the input/output device 145 or the host processor 120, or any other peripheral device, may connect to this pin to trigger the soft reset. The INIT# signal may be received by the bus interface unit 155 and relayed to the CPU core 1 10 via a control line on the CPU local bus 165. In addition, after resetting, the BIOS code must be modified to insure that refresh to the DRAM 225 begins very soon after reset.

The use of the soft reset causes another problem, however. If a cache memory is provided in the system, as shown for example in Figure 2, the use of the soft reset typically does not flush the cache memory 175. As a result, "dirty" data may exist in the cache memory, which is inconsistent with the related data in DRAM 225. In addition to retrieving internal CPU state values, it also is desirable to retrieve the contents of system memory 225 to determine the mapping of the memory during the execution of certain software programs, and the data located in the various areas of memory. If the data in memory 225 has been modified in the cache memory 175 and not yet copied to system memory 225, the system memory 225 will not reflect the true data in the system. Because of this potential coherency problem, the present invention envisions several alternative procedures for insuring coherency between the data in the cache memory 175 and the system memory 225.

The first approach to prevention of cache incoherency with system memory 225 is to include with the trigger mechanism an instruction to flush the cache memory 175. Thus, for example, the microcode patch in the ROM on card 190. which modifies existing microcode ROM instructions, may be modified to include an instruction to dump internal state values and to flush cache. A second method to prevent cache incoherency is to immediately flush the cache memory when coming out of reset, as one of the first steps in the BIOS boot code. During the BIOS boot sequence, and as shown in the exemplary embodiment of Figure 3, the CPU 1 10 preferably reserves a block of space in the system memory 225 exclusively for receiving the CPU internal state information during a state dump. According to conventional techniques, the reservation of space in the system memory is implemented by indicating a base address in memory and a limit or size. In this manner, the memory control unit 140, or a similε device, is cognizant of the starting address and ending address of the reserved space. Other space in memory 225 may also be reserved at the same time for other functions.

Having described the structure and general methods of the preferred embodiment, reference is now made to Figure 5, which shows a flow chart, according to the preferred embodiment, for performing the BIOS boot code to implement the present invention. Referring now to Figures 2 and 5, after the CPU 1 10 is reset, the CPU in step 302 preferably sends a signal to the cache controller 180 causing the cache memory 175 to flush dirty data to the system memory 225. As one skilled in the art will realize, this step only is necessary if a cache memory 175 is provided in the system, and if the cache memory is enabled to contain dirty data. Moreover, as discussed above, the flushing of the cache 175 may occur prior to reset if the state dump mechanism is appropriately programmed. Such programming could be obtained by instructions in microcode or by using a microcode patch, as described above.

In step 304, the CPU 1 10 enables the refresh timer to insure that the contents in DRAM 225 are not lost. Preferably, the reset is initiated by a soft reset, such as by asserting the INIT# pin. If a soft reset is made, the refresh will continue during the reset operation. In step 306, the BIOS code instructs the CPU 1 10 to reserve space in system memory 225 for storing CPU internal values if a state dump should occur. According to the preferred embodiment, the space preferably comprises I28Λbytes, and is identified by specifying a base address and a limit or size. Other blocks in DRAM may be stored as part of step 306, if desired.

The CPU 1 10 scans the reserved state dump region 295 (Figures 3 and 4) in step 308 to determine if a valid signature is present in the signature block (identified as the SIGNATURE block in Figure 4). If the CPU determines in step 310 that a valid signature is not present in the signature block, the CPU continues with a normal boot sequence, as indicated in step 31 1. If, conversely, a valid signature is present in the signature block, the CPU aborts a normal boot sequence and proceeds with a subroutine to transfer the state dump values from DRAM 225 to an external device such as host processor 120. Although not expressly listed in Figure 5, it should be noted that the CPU will not test the DRAM prior to checking for a signature in step 310. If a signature is present, the reserved block of DRAM is not tested thus insuring that the integrity of the stored data is maintained during the testing procedure. If no signature is present, the DRAM may be tested as part of a standard boot sequence. As noted above, during a state dump operation the CPU provides a signature in the signature block identifying the processor and identifying the mechanism by which the state dump was triggered.

Accordingly, in step 312, the CPU 1 10 performs a check sum of the binary values in the state dump region of DRAM. The CPU then performs a two's complement of the check sum value and stores the complemented check sum value in the last byte of the reserved memory block (shown as the CHECK SUM byte in Figure 4). In step 314. the CPU initializes the serial port for transmission to the host processor 120 over serial bus 1 15. Alternatively, if the host processor 120 connects to the integrated processor 100 through a different bus, or if the state dump data is to be transmitted elsewhere, the appropriate output port is initialized in step 314 to accomplish the transfer.

The CPU transmits the state information in the DRAM 225 to the host processor 120 in step 316. The CPU then monitors the ser l bus 1 15 for a command from the host processor 120 or from input/output device 145, as indicated in step 318. The CPU will stay in this wait state until a command is received, or until the user again resets the CPU. Other alternative steps may also be appropriate in the wait state condition. For example, the CPU may default into reset if no command is received after a defined period of time.

If a command is received by the CPU from the host 120 or input/output device 145, the CPU 1 10 checks the command in step 320 to determine if the host or input/output device 145 has requested that the state information be re-transmitted. If so, the CPU branches back to step 316 and transmits the state information again. Conversely, if the command requests a read to a different memory location, the CPU, or other processor components, receive the requested memory address and decode it in step 322 to determine the address requested. In the preferred embodiment, the command signal comprises a six byte signal. The first four bytes indicate the starting address for the read cycle, while the remaining two bytes indicate the limit or size of the requested address. After the address is decoded, the data located at the requested address is transmitted to the host processor, as indicated in step 324. The CPU then zeros out the signature block in step 326 and proceeds to the wait state, looking for further commands from the host until the CPU is reset.

Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

WHAT IS CLAIMED IS:

1. A system for testing a processor, comprising; a system memory connected to said processor; a host processor connected to said processor for transmitting signals to said processor and receiving signals from sak'. processor: wherein said processor dumps its internal state values to said system memory in response to a specific trigger mechanism when the processor is in a hung state.

2. A system as in claim 1 , wherein said processor includes a microcode ROM for storing microcode instructions, and said microcode instructions include an instruction for transmitting internal state values to system memory in response to receipt of said trigger mechanism.

3. A system as in claim 2, wherein said trigger mechanism comprises the assertion of a specific input line to the processor.

4. A system as in claim 2, further comprising; an external bus connected to said processor; and an external ROM device connected to said external bus; wherein said external ROM includes modified microcode instructions for performing the transmission of internal state values to system memory in response to receipt of said trigger mechanism.

5. A system as in claim 1 , wherein said processor comprises an integrated processor.

6. A system as in claim 5, wherein said integrated processor includes a CPU core and a memory control unit for coordinating the transfer of data between the CPU core and the system memory.

7. A system as in claim 6, wherein said integrated processor further includes a bus interface unit for coordinating the transfer of signals between said CPU core and said host processor.

8. A system as in claim 6, further comprising a BIOS ROM, connected to said memory control unit, for storing BIOS boot code.

9. A system as in claim 8, further comprising a cache memory and a cache controller connected to said CPU via a cache bus.

10. A system as in claim 9. wherein said CPU core flushes the contents of said cache memory at substantially the same time that internal state values are transferred to the system memory.

1 1. A system as in claim 9, wherein said CPU core flushes the contents of said cache memory before beginning a boot sequence.

12. A system as in claim 6, wherein said CPU core transmits a signal to said memory control unit reserving a block of system memory for storing CPU internal state values.

13. A system as in claim 1 , wherein said processor continues to refresh the system memory during reset of the processor.

14. A system as in claim 1, wherein said processor enables refresh to said system memory before beginning a boot sequence.

15. A system as in claim 1, wherein said host processor connects to said processor via a serial bus.

16. A system as in claim 1, wherein said processor provides a signature with said internal state values to validate the data stored in said system memory.

17. A system as in claim 16, wherein said processor checks for the presence of said signature after being reset, and before beginning a boot sequence.

18. A system as in claim 17, wherein said processor aborts the boot sequence if the signature is present.

19. A system for testing a processor, said processor including a CPU comprising; a system memory connected to said processor via a memory bus; an internal read only memory unit in said CPU in which instructions are embedded for controlling the operation of said processor, said instructions including an instruction to dump the internal state values of the CPU to the system memory in response to a trigger mechanism; an external device connected to said processor for initiating said trigger mechanism; and a ROM device containing BIOS boot code for initializing the CPU after a reset, said BIOS boot code including instructions to reserve a block of system memory for receiving the internal state values of the CPU.

20. A system as in claim 19, further comprising a cache memory connected to said CPU, and wherein said BIOS boot code includes instructions to flush the cache memory.

21. A system as in claim 19, wherein said BIOS boot code includes instructions to initiate refresh of the system memory.

22. A system as in claim 19, wherein said CPU writes a signature into system memory when dumping the internal state values to system memory to validate the state values.

23. A system as in claim 22, wherein said BIOS boot code includes an instruction directing the CPU to scan system memory for the signature.

24. A system as in claim 23, wherein said BIOS boot code includes an instruction aborting a normal boot sequence if the signature is present in system memory.

25. A system as in claim 19, wherein said ROM device connects to said memory bus.

26. A system as in claim 25, wherein said processor also includes a memory control unit connected to said memory bus.

27. A system as in claim 26, wherein said memory bus connects to said CPU via a local bus.

28. A system as in claim 19, wherein said external device comprises a host processor.

29. A system as in claim 28, wherein said host processor connects to said processor via a serial bus.

30. A system as in claim 19, wherein said external device comprises an input/output device.

31. A system as in claim 30, wherein said input/output device connects to said processor via a system bus.

32. A system as in claim 31, further comprising an external patch ROM connected to said system bus.

33. A system as in claim 32, wherein said external patch ROM includes instructions modifying a selected microcode instruction in said internal read only memory unit.

34. A system for saving internal state values of a CPU during the testing of an integrated processor, comprising; a host processor connected to said integrated processor for testing said integrated processor; a system memory connected to said integrated processor by a memory bus; a BIOS ROM connected to said integrated processor by said BIOS ROM; wherein said integrated processor includes; a memory control unit connected to said memory bus, said memory bus also being connected to said CPU via a local bus; and a cache memory connected to said CPU by a cache bus. and wherein said cache is capable of storing and updating data that has been read from the system memory: and wherein said CPU dumps its internal state values to said system memory in response to a hang state of the processor, and said CPU further flushes the updated data in said cache memory back to said system memory.

35. A system as in claim 34, wherein said CPU also must receive a trigger signal from an external device prior to dumping its internal state values.

36. A system as in claim 35, wherein the trigger signal is initiated by an operator.

37. A system as in claim 36, wherein said CPU includes an internal microcode ROM storing microcode instructions, and said microcode instructions include an instruction directing the CPU to dump its internal state values in response to receipt of said trigger signal.

38. A system as in claim 34, wherein said BIOS ROM includes boot code for initiating operation of the processor after a reset.

39. A system as in claim 38, wherein said processor maintains refresh to said system memory during reset.

40. A system as in claim 38. wherein said CPU provides a check sum value as part of its internal state dump.

41. A system as in claim 40. further comprising a host processor connected to said processor.

42. A system as in claim 41 , wherein said CPU transmits the internal state values from said system memory to said host processor after a reset.

43. A system as in claim 42, wherein said host processor checks the validity of the transmission by generating a check sum value and comparing that check sum value with the check sum value stored in system memory.

44. A system as in claim 43, wherein said CPU writes a signature as part of the internal state dump.

45. A method of saving internal state values of a CPU during debugging of a processor, comprising the steps of; reserving space in system memory for storing the CPU internal state values; dumping internal state values to system memory together with a signature in response to a trigger mechanism; resetting the CPU; refreshing the system memory during reset: checking for the presence of said signature: transmitting the internal state values from system memory to an external device for analysis if said signature is present.

46. A method as in claim 45, further comprising the step of flushing a cache memory.

47. A method as in chim 45, further comprising the step of again reserving the space in system memory for storing the CPU internal state values after resetting.

48. A method as in claim 45, further comprising the step of performing a two's complement check sum of the binary values in the reserved space in memory.

49. A method as in claim 45, further comprising the step of writing said two's complement check sum to the last byte in said reserved space.

50. A method as in claim 49, further comprising the step of comparing said check sum in said reserved space with a check sum value calculated by said external device.

51. A method as in claim 45, wherein said external device transmits commands to said processor requesting additional data from said system memory.