WO1996038790A1

WO1996038790A1 - A system and method for patching microcode during the debugging of a processor

Info

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

Abstract

The present invention discloses a system and method for patching revised microcode during debugging of a microprocessor to permit the revised microcode to be verified in a system environment prior to committing to silicon. The microprocessor includes an internal ROM in which microcode is embedded. If an error is detected in the microcode, a flag bit is set, and the microprocessor retrieves revised microcode from an external memory. The external memory may comprise an external ROM, on a card that plugs into an external peripheral bus. Alternatively, the external memory may comprise system memory. The microcode is loaded in system memory from a disk driver, such as an integrated hard drive, or a floppy disk drive. The microcode is stored in a reserved place in memory, and the BIOS is modified to preserve the security of the reserved portion of memory.

Description

TITLE: A SYSTEM AND METHOD FOR PATCHING MICROCODE

DURING THE DEBUGGING OF A PROCESSOR

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 debugging of new microprocessors necessitated by erroneous microcode instructions. Still more particularly, the present invention relates to a technique for facilitating the debugging of microcode in a processor design without requiring the production of new processor prototypes.

2. Description of the Relevant Art

Microprocessors 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 microprocessors, 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 microprocessor 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."

As one skilled in the art will understand, microprocessors include an instruction set which dictate the operation and capabilities of the processor design. The instructions that comprise the instruction set commonly are referred to as microcode. The microcode may be embedded in a microcode read only memory (MROM) unit located in the microprocessor, and access to the microcode instructions through other programs typically is completely prohibited. The microcode can be thought of as a program, installed in the microprocessor, which controls the basic operations and functions of the processor.

One of the portions of the microprocessor design that requires debugging is the microcode itself. As the microprocessor is tested, errors may be discovered in the microcode instructions. Because of the limited access to the microcode, the microcode only is changed in current practices when new prototypes are produced for successive designs. Furthermore, when errors are found in the microcode, all related debugging is stopped, because it is inefficient to modify the processor hardware when the associated microcode will be revised. Consequently, further debugging in all related areas is halted until the new prototypes are produced. Under current practices, when errors (or bugs) are found in the microcode instructions, these errors are documented and provided to system designers Typically, the system designers run simulations to find ways to change the microcode to correct the errors detected Under present practices, these changes cannot be effectively tested until the next prototype is produced, with the changes to the microcode embedded in the internal ROM of the subsequent processor prototype

The problem with this approach is that the changes to the microcode cannot be verified in the system environment before the changes are committed to silicon This procedure can greatly increase the cost and time expended during the design process, as unverified changes are made to the microcode and incorporated in a subsequent prototype of the microprocessor, only to fail

It would be advantageous if changes to the microcode could be tested in the system prior to incorporation in a prototype While the advantages of such a procedure are apparent to one skilled in the art, to date no one has developed such a procedure

SUMMARY OF THE INVENTION

The problems outlined above are in large part solved by the teachings of the present invention The present invention incorporates a technique for patching existing microcode instructions in microcode read only memory (MROM) with revised instructions without requiring production of new silicon chip prototypes The patching of the microcode permits the proposed microcode changes to be intensively verified in the svstem environment before the changes are committed to a subsequent processor fabrication

The patching mechanism of the present invention may be implemented in one of two ways The first way to implement the patching is to provide a revised image of the microcode in an external read only memory (ROM) unit According to this embodiment, the ROM preferably is located on a plug-in card, with an address decoder and data buffers The ROM unit couples to an external peripheral system bus, which in turn couples to the microprocessor (also referred to as CPU or central processing unit) The microcode image, with any desired changes, preferably is located in a reserved memory address in the external ROM unit, such as, for example, D8000h in a PC/AT system

The second way to implement the patching mechanism is to place the revised microcode into dvnamic random access memory (DRAM), which according to normal convention, comprises the working memory of the microprocessor or CPU The microcode can be loaded in DRAM either through a hard drive or a floppy drive The DRAM preferably connects to the microprocessor via a memory bus, and a memory controller preferably is provided as part of the microprocessor to control transactions to the DRAM The CPU accesses the memory controller via a local bus The microcode image, with anv desired changes preferably is loaded in a reserved memoiΛ address in the DRAM such as tor example D8000h In the preferred embodiment, the microcode is loaded into an on-chip 32Abyte microcode ROM unit in the microprocessor. The microcode preferably includes one or more flag bits for indicating that certain segments of the code, or all of the code, should be retrieved externally. If the flag bit is set for a particular instruction, the CPU will branch to an external memory controller to retrieve that portion of the microcode from the external memory unit. According to the prefer-ed embodiment, the default condition for the CPU is to seek the patched microcode from the external bus. If an appropriate bit has been set in a configuration register, then the CPU will seek the patched microcode from DRAM.

To implement the present invention, the BIOS must be modified to indicate where the patched microcode is located and to prevent use of that memory location for other purposes. In addition, a bit is set in an appropriate configuration register to indicate whether the patched microcode is located on the external bus or in DRAM. When the central processing unit (CPU) seeks to read patched microcode from an external memory, the read request is routed according to the status of the dedicated configuration bit.

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 is a block diagram representation of the present invention;

Figure 2 is a block diagram illustration depicting an exemplary embodiment of the present invention;

Figure 3 is a block diagram illustration depicting an alternative embodiment of the present invention;

Figure 4 is a flow chart showing the general methodology by which microcode patching occurs; and

Figure 5 is a block diagram illustration of the preferred embodiment of the present invention which implements the alternative embodiments of Figures 2 and 3.

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 limit 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 circuit design which is being tested to determine if it will perform satisfactorily. In the preferred embodiment of Figure 1 , the device under test (DUT) comprises a microprocessor (or processor) 10, which includes an internal read only memory (ROM) 15. The test equipment and connections have been omitted from Figure 1 for the sake of simplicity. The processor 10 operates according to preprogrammed instructions, commonly referred to as microcode. In the preferred embodiment, the processor 10 is tested in a personal computer (PC) system, its intended environment. The present invention facilitates testing of the processor 10 in this environment by permitting changes to be made in the processor microcode, without requiring the production of new prototypes. In the preferred embodiment of the present invention, the microcode is 32Aby.es long and is stored in the internal microcode ROM (or MROM) 15 of the processor 10.

As the processor undergoes testing in the system environment, it may become apparent that certain instructions in the microcode are improper, resulting in erroneous operation of the processor 10. According to the preferred embodiment of the present invention, a portion, or all, of the microcode can be replaced or patched with revised microcode contained on an external memory device 25. Whether the processor 10 patches microcode from the external memory device 25 is determined by a flag bit associated with the microcode. If the dedicated flag bit is set, the processor 10 seeks the microcode patch from the memory device 25, and operates according to the patched microcode. In the preferred embodiment, a flat bit is associated with each instruction in the microcode, so that each instruction can be patched separately. Thus, if a particular instruction has been found to be erroneous, an associated flag bit for that instruction is set to indicate that in subsequent testing, that instruction should be patched from external memory.

The memory device 25 preferably connects to the processor 10 via an external bus 20. In response to a read request from the processor 10, the memory device drives out the desired data onto the bus 20, in accordance with conventional techniques. In the preferred embodiment, the memory device 25 has stored therein an image of the microcode, with any desired revisions. The microcode image 30 preferably is stored in a reserved space in the memory device 25, so that the image 30 is not disturbed by other operations of the processor 10.

In the preferred embodiment, the microcode image 30, which also is 32Abytes long, is stored in the memory device 25 starting at address D8000h. As one skilled in the art will understand, the C0000 - DFFFF segment of memory is reserved for optional ROM in PC/AT systems. The microcode image 30, therefore, preferably is stored in the upper half of this reserved space, and the system BIOS (basic input-output system) is notified during system initialization that the D8000h - DFFFFh segment is reserved for the microcode patch 30. If an architecture other than PC/AT is implemented (such as microchannel), then the microcode patch would be located in a similar reserved space in memory.

Figure 1 illustrates the general concept of providing a microcode patch in an external memory device. Exemplary embodiments for implementing the present invention are shown more specifically in Figures 2 and 3. In addition to the embodiments of Figures 2 and 3, the present invention could be implemented in the BIOS (basic input/output system) ROM. if sufficient space exists for the revised microcode image. Referring now to the exemplary embodiment of Figure 2, the device under test (DUT) preferably comprises a processor 100. The processor 100 preferably includes a central processing unit (CPU) core 1 10, and a CPU local bus 165 coupled to the CPU core 1 10. A bus bridge 155 preferably couples to the processor 100 through a peripheral bus 120.

The CPU core 1 10 preferably includes an internal ROM 1 15 on 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, an external bus 120 (such as an ISA bus, a PCI bus, or an EISA bus) couples to the CPU local bus 165 through a suitable bus bridge 155. The bus bridge 155 provides a standard interface between the CPU local bus 165 and the peripheral bus 120. As such, the bus bridge 155 orchestrates the transfer of data, address, and control signals between the two buses. The bus bridge 155 preferably includes configuration registers 175 to control the routing of signals in the PC system.

In the exemplary embodiment of Figure 2, a plug-in card 150 connects to the peripheral bus 120. As one skilled in the art will realize, the components on card 150 may alternatively be included in the system via a hard wire connection to the peripheral bus 120. According to the embodiment of Figure 2, the plug-in card 150 preferably includes a read only memory device (ROM) 125, on which the revised microcode patch has been stored. The card 150 also includes an address decoder 135 and data buffers 140. Preferably, an off-the-shelf external ROM card is used to implement the present invention, with the revised microcode loaded onto the ROM. Such off-the-shelf cards currently are available for connecting to an ISA bus, for example.

As one skilled in the art will understand, the address decoder 135 receives address signals transmitted on the peripheral bus 120, and decodes those signals. If the address specifies a valid address in ROM 125, the decoded address signals are applied to the ROM on the address bus 170 in accordance with conventional techniques. The data buffers 140 provide coupling between the ROM 125 and the peripheral bus 120. Thus, the data buffers 140 receive data signals from ROM 125 and drive those data signals out onto the peripheral bus 120.

Referring still to Figure 2, during the testing of the processor 100, the CPU core 1 10 will periodically access the microcode stored in the internal ROM 1 15 for certain operations. If errors are detected in the microcode instructions, then the microcode is revised and loaded on the external ROM device 125. The ROM device 125 is coupled to the processor 100 via the external peripheral bus 120. In subsequent operation, the CPU will patch certain existing microcode instructions from the external ROM device 125 if an associated flag bit is set. Instead of reading microcode from the MROM 1 15, therefore, the CPU 1 10 reads revised microcode instructions from the external ROM device 125.

Referring now to the exemplary embodiment of Figure 3, a processor 200 is shown, which preferably is designed for use with a computer system. In accordance with the principles of the present invention, the processor 200 comprises a device under test. The processor 200 in the exemplary embodiment of Figure 3 includes a CPU core 210, a bus bridge 255, and a memory control unit 230. For the present discussion, it can be assumed that CPU core 210 is identical to that shown as CPU core 1 10 in Figure 2, and that bus bridge 255 is identical to the bus bridge 155. Thus, CPU core 210 includes an internal ROM 215 and bus bridge 255 includes configuration register 275 and orchestrates the transfer of address, data and control signals between the CPU local bus 265 and a peripheral bus 220.

The memory control unit of Figure 3 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.

The DRAM banks, according to normal convention, comprise the working memory of the processor 200. In the exemplary embodiment of Figure 3, a 32Λbyte segment of memory is reserved in DRAM 225 to store the revised microcode image. In the preferred embodiment of the present invention which contemplates use in a PC/AT system, the reserved microcode segment starts at address D8000h.

If the existing microcode stored in internal ROM 215 is found to be erroneous, a revised microcode image preferably is loaded in the reserved space of DRAM 225 from either an integrated hard drive of a personal computer system, or from a floppy disk. A disk driver 230 is shown in Figure 3 connected to the peripheral bus 220. The disk driver may comprise either an IDE driver for a hard drive, or a floppy disk drive for a floppy disk. Data from the hard drive or floppy disk is retrieved by disk driver 250 and driven onto the peripheral bus 220 in accordance with well known techniques. The bus bridge 255 orchestrates the transfer of this data to the memory control unit 230, which in turn controls the writing of this data to the reserved space in DRAM 225.

In the preceding discussion, the embodiments of Figures 2 and 3 have been presented as alternative system embodiments. Preferably, the embodiments of Figures 2 and 3 are both implemented in the system and are both available as vehicles to patch faulty microcode to the processor under test. As such, the microprocessor 500 preferably is constructed as shown in Figure 5, with a CPU core 510, a memory control unit 530, and a bus bridge 55. In the preferred embodiment, the revised microcode can be patched either by an external ROM plug-in card 150 (which is identical to that described in Figure 2) or by loading the revised microcode in DRAM 225 (which identical to the DRAM of Figure 3), as desired by the user. The CPU core 510 preferably includes an internal microcode ROM (or MROM) 515 for storing microcode. The bus bridge 555 preferably includes a configuration register 575 for indicating the manner in which the computer system is configured. As one skilled in the art will recognize, register 575 may be located separately from bus bridge 555. In the preferred embodiment, configuration register 575 preferably includes a dedicated bit to indicate whether the revised microcode patch is to be retrieved from the external ROM 125 on external bus 120, or from DRAM 225. The dedicated bit preferably defaults to indicate that the microcode patch is located in external ROM 125. A user may, however, change the dedicated bit in register 575 to indicate that the revised microcode patch has been stored in DRAM 225. According to the preferred embodiment, the bus bridge 555 indicates to the CPU whether to route patch requests to the DRAM or to the external bus, based upon the status of the dedicated bit in register 575.

In accordance with the preferred embodiment, the processor 510 is tested in a PC system environment. If during this testing, it is discovered that existing microcode is erroneous, the microcode is revised in an attempt to eliminate the discovered errors. In addition, all erroneous instructions in the microcode are tagged with an associated flag bit to indicate the instruction is erroneous. The revised microcode patch is loaded into an external memory device (preferably at a designated address of D8000h in a PC/AT), which may be either external ROM or DRAM, and testing is resumed.

Referring now to Figure 4, the preferred methodology for patching this revised microcode will now be described. If during testing, a microcode instruction is encountered with a tagged flag bit, the CPU core preferably follows the routine outlined in the flow chart of Figure 4.

Initially, the bus bridge determines in step 402 whether the microcode patch is located in DRAM or on the external bus. If the microcode patch is in DRAM, the chipset is setup for a DRAM access to the reserved location (step 404), which in a PC/AT system preferably is address D8000h. After the chipset is setup in step 404, the

32/ιbyte patch is loaded into DRAM from the disk driver in step 406. Conversely, if the microcode patch is located in an external ROM device on the external bus, the chipset is setup in step 405 for bus access to the reserved patch location.

In step 410, the processor is setup with a patch base that is the same as the base address of the microcode patch in memory. Thus, in the preferred embodiment, the processor is setup with a patch base of D8000h. Subsequently, in step 412, the processor obtains the address of the instruction to be patched from the command line, and uses this address as the offset for the patch base. The processor in step 412 retrieves the patched instruction located at the offset address of the microcode patch, and implements this instruction in place of the erroneous instruction in the MROM. In step 414, the CPU determines if the command line is complete. If it is, the patch is complete. If the command line has not been completed, the CPU returns to step 410. 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 device, comprising; an internal read only memory unit in said device in which instructions are embedded for controlling the operation of said device; a peripheral bus coupled to said device; and an external memory unit coupled to said peripheral bus, said external memory unit having stored therein revised instructions; wherein said device is capable of substituting the revised instructions for the embedded instructions.

2. A system as in claim 1 , wherein the device comprises a processor.

3. A system as in claim 2, wherein the external memory unit comprises an external ROM located on a plug-in card.

4. A system as in claim 3, wherein the peripheral bus comprises an ISA bus, and said plug-in card connects to said ISA bus.

5. A system as in claim 2, wherein the external memory unit comprises system memory.

6. A system as in claim 5, wherein the system memory is constructed of DRAM circuits.

7. A system as in claim 6, wherein the processor includes a memory control unit coupled to said DRAM circuits via a memory bus.

8. A system as in claim 7, wherein the processor includes a configuration register with a dedicated bit to indicate the revised instructions are stored in DRAM.

9. A system as in claim 1 , wherein space is reserved in said external memory unit for storing said revised instructions.

10. A system as in claim 9, wherein the revised instructions are the same length as the embedded instructions.

1 1. A system for debugging a microprocessor, said microprocessor including an internal read only memory on which microcode is embedded, said system comprising; a peripheral bus coupled to said microprocessor; an external ROM connected to said peripheral bus, said external ROM having stored therein revised microcode; wherein said microprocessor retrieves said revised microcode from said external ROM when the embedded microcode is found to be erroneous.

12. A system as in claim 1 1. wherein said microprocessor includes a bus bridge connected to said peripheral bus.

13. A system as in claim 12, wherein said microprocessor includes a CPU local bus connected to said bus bridge.

14. A system as in claim 13, wherein said microprocessor includes a CPU core connected to said CPU local bus, and the internal read only memory is located in said CPU core.

15. A system as in claim 1 1 , wherein said external ROM is located on a card which plugs into said peripheral bus.

16. A system as in claim 1 1 , wherein said revised microcode is stored in a reserved section of memory.

17. A system as in claim 16. wherein the reserved section of memory starts at D8000h.

18. A system as in claim 17, wherein the revised microcode has a length equal to the length of the embedded microcode.

19. A system for debugging a microprocessor, said microprocessor including an internal read only memory on which microcode is embedded, said system comprising; an external peripheral bus coupled to said microprocessor; a disk driver connected to said peripheral bus, said disk driver electrically connected to a storage medium, said storage medium having stored therein revised microcode; system memory connected to said microprocessor via a memory bus; wherein said microprocessor loads the revised microcode in system memory, and subsequently retrieves said revised microcode from system memory when the embedded microcode is found to be erroneous.

20. A system as in claim 19, wherein the storage medium comprises an integrated hard drive.

21. A system as in claim 19, wherein the storage medium comprises a floppy disk.

22. A system as in claim 19. wherein the system memory is comprised of dynamic random access memory.

23. A system as in claim 22, wherein said microprocessor includes a memory control unit connected to said memory bus for controlling transactions to said dynamic random access memory.

24. A system as in claim 23, wherein said microprocessor includes a CPU core connected to said memory controller by a CPU local bus.

25. A system as in claim 24, wherein the internal read only memory is located in said CPU core.

26. A system as in claim 25. wherein said microprocessor includes a bus bridge connected to said external peripheral bus.

27. A system as in claim 26, wherein the bus bridge includes a configuration register with a bit dedicated to indicating whether revised microcode is stored in DRAM.

28. A system as in claim 27, wherein the microcode is stored in a reserved section of DRAM.

29. A system as in claim 28, wherein the reserved section of DRAM starts at address 8000h.

30. A system as in claim 29, wherein the microcode has a length equal to the length of the embedded microcode.

31. A method of patching revised microcode to a microprocessor during debugging of the microprocessor, comprising the steps of; loading the revised microcode into external memory; reserving the address in memory at which the revised microcode is loaded; testing the microprocessor; detecting a flag to indicate that a patch is requested; retrieving the revised microcode from external memory; and operating the microprocessor according to the revised microcode.

32. A method as in claim 31, wherein the external memory comprises DRAM.

33. A method as in claim 32, further comprising the step of setting a dedicated bit to indicate that the revised microcode is stored in DRAM.

34. A method as in claim 33, wherein the step of loading the revised microcode into external memory includes the steps of; retrieving the revised microcode from a disk driver; and storing the revised microcode in a section of DRAM.

35. A method as in claim 34. wherein said disk driver comprises an integrated driver for a hard drive.

36. A method as in claim 35, wherein said disk driver comprises a floppy disk drive.

37. A method as in claim 31 , wherein the external memory comprises an external ROM.