CN104331387B - microprocessor and configuration method thereof - Google Patents

Abstract

The invention provides a microprocessor and a configuration method thereof. The microprocessor includes an instruction and a plurality of processing cores. Each processing core of the plurality of processing cores is configured to sample the indication. When the indication indicates a first preset value, the processing cores are configured to commonly designate the processing cores of the processing cores as a steering processor. When the indication indicates a second predetermined value different from the first predetermined value, the processing cores are configured to collectively designate a single processing core of the processing cores as the steering processor. The invention has less power consumption.

Description

Microprocessor and its configuration method

technical field

The present invention relates to a microprocessor, and more particularly to the selective designation of multiple cores among multiple cores as the lead processor.

Background technique

The increase in multi-core microprocessors is mainly due to the advantages in performance they provide. This may be primarily due to the rapid reduction in the size of semiconductor device geometries, thereby increasing transistor density. The presence of multiple cores in a microprocessor has created a need for one core to communicate with other cores to perform various functions such as power management, cache memory management, debugging and configuration related to more cores.

Traditionally, programs (eg, operating systems or applications) running on architectures on multi-core processors have communicated using semaphores located in a system memory architecturally addressable by all cores. This may be sufficient for many purposes, but may not provide other desired speed, accuracy and/or system level transparency.

Contents of the invention

The invention provides a microprocessor. The above-mentioned microprocessor includes an instruction and multiple processing cores. Each processing core of the plurality of processing cores is configured to sample the indication. When the indication indicates a first preset value, the plurality of processing cores are configured to jointly designate a plurality of processing cores of the plurality of processing cores as a Bootstrap Processor (BSP). When the indication indicates a second default value different from the first default value, the plurality of processing cores are configured to jointly designate a single processing core of the plurality of processing cores as the guide processor.

The invention provides a method of configuring a multi-core microprocessor. The method includes: sampling an indication of the microprocessor; when the indication indicates a first preset value, specifying a plurality of processing cores of the plurality of processing cores in the multi-core microprocessor as a guide processor; and When the indication indicates a second default value different from the first default value, designate a single processing core of the plurality of processing cores as the guide processor.

The invention provides a computer program product encoded on at least one non-transitory computer usable medium used in a computer device, said computer program product comprising computer usable program code indicating a microprocessor. The computer-usable program code includes: first program code indicating an indication; and second program code indicating a plurality of processing cores. Each of the plurality of processing cores is configured to sample the indication. When the indication indicates a first preset value, the plurality of processing cores are configured to jointly designate a plurality of processing cores of the plurality of processing cores as a Bootstrap Processor (BSP). When the indication indicates a second default value different from the first default value, the plurality of processing cores are configured to jointly designate a single processing core of the plurality of processing cores as the guide processor.

The present invention has less power consumption.

Description of drawings

FIG. 1 is a block diagram showing a multi-core microprocessor.

FIG. 2 is a block diagram showing a control word, a status word and a configuration word.

Fig. 3 is a flowchart showing the operation of a control unit.

FIG. 4 is a block diagram showing another embodiment of a microprocessor.

FIG. 5 is a flowchart showing the operation of a microprocessor to dump debug information.

FIG. 6 is a timing diagram showing an example of the operation of the microprocessor according to the flowchart of FIG. 5 .

7A-7B are flowcharts showing a microprocessor performing cross-core cache control operations.

FIG. 8 is a timing chart showing an example of the operation of the microprocessor according to the flowcharts of FIGS. 7A to 7B.

9 is a flowchart showing the operation of a microprocessor entering a low power package C-state.

FIG. 10 is a timing chart showing an example of the operation of a microprocessor according to the flowchart of FIG. 9. FIG.

FIG. 11 is a flowchart of the operation of a microprocessor entering a low power package C-state according to another embodiment of the present invention.

FIG. 12 is a timing chart showing an example of the operation of the microprocessor according to the flowchart of FIG. 11. Referring to FIG.

FIG. 13 is a timing chart showing another example of the operation of the microprocessor according to the flowchart of FIG. 11. Referring to FIG.

Figure 14 is a flowchart showing dynamic reconfiguration of a microprocessor.

FIG. 15 is a flowchart illustrating dynamic reconfiguration of a microprocessor according to another embodiment.

FIG. 16 is a timing chart showing an example of the operation of the microprocessor according to the flowchart of FIG. 15. FIG.

FIG. 17 is a block diagram showing the hardware semaphore 118 in FIG. 1 .

FIG. 18 is a flowchart showing the operation when a core 102 reads the hardware semaphore 118 .

FIG. 19 is a flowchart showing the operation when a core writes to a hardware semaphore.

FIG. 20 is a flow chart showing the operation of a microprocessor using hardware semaphores to perform operations requiring exclusive ownership of a resource.

FIG. 21 is a sequence diagram showing an example of an operation of issuing a non-sleep synchronization request by a core according to the flowchart of FIG. 3 .

Fig. 22 is a flowchart showing a program for configuring the microprocessor.

FIG. 23 is a flow chart showing a procedure for configuring a microprocessor according to another embodiment.

FIG. 24 is a block diagram showing a multi-core microprocessor according to another embodiment.

Figure 25 is a block diagram showing a microcode patch architecture.

26A-26B are flowcharts showing an operation of the microprocessor in FIG. 24 to propagate a microcode patch of FIG. 25 to the multi-cores of the microprocessor.

Fig. 27 is a timing chart showing an example of the operation of a microprocessor according to the flowcharts of Figs. 26A to 26B.

FIG. 28 is a block diagram showing a multi-core microprocessor according to another embodiment.

29A-29B are flowcharts illustrating an operation of the microprocessor in FIG. 28 for propagating a microcode patch to multiple cores of the microprocessor according to another embodiment.

FIG. 30 is a flowchart showing the microprocessor of FIG. 24 for patching a service processor program code.

FIG. 31 is a block diagram showing a multi-core microprocessor according to another embodiment.

32 is a flowchart showing an operation of the microprocessor of FIG. 31 for propagating a MTRR update to the cores of the microprocessor.

Among them, a brief description of the symbols in the drawings is as follows:

100: multi-core microprocessor; 102A, 102B, 102N: core A, core B, core N; 103: non-core; 104: control unit; 106: status register; 108A, 108B, 108C, 108D, 108N: synchronization register 108E, 108F, 108G, 108H: shadow synchronous register; 114: fuse; 116: dedicated random access memory; 118: hardware semaphore; 119: shared cache memory; 122A, 122B, 122N: time Pulse signal; 124A, 124B, 124N: interrupt signal; 126A, 126B, 126N: data signal; 128A, 128B, 128N: power control signal; 202: control word; 204: wake-up event; 206: synchronous control; 208: power gate ; 212: Sleep; 214: Selective wakeup; 222: S; 224: C; 226: Synchronous state or C-state; 228: Core collection; 232: Forced synchronization; ;242: status word; 244: wakeup event; 246: lowest common C-state; 248: error code; 252: configuration word; 254-0~254-7: enable; 256: local core number; 258: crystal number ; 302, 304, 305, 306, 312, 314, 316, 318, 322, 326, 328, 332, 334, 336: steps; 402A, 402B: inter-crystal bus unit A, inter-crystal bus unit B; 404: crystal Inter-bus; 406A, 406B: crystal A, crystal B; 502, 504, 505, 508, 514, 516, 518, 524, 526, 528, 532: steps; 702, 704, 706, 708, 714, 716, 717 , 718, 724, 726, 727, 728, 744, 746, 747, 748, 749, 752: steps; 902, 904, 906, 907, 908, 909, 914, 916, 919, 921, 924: steps; 1102 , 1104, 1106, 1108, 1109, 1121, 1124, 1132, 1134, 1136, 1137: steps; 1402, 1404, 1406, 1408, 1412, 1414, 1416, 1417, 1418, 1422, 1424, 1426: steps; , 1504, 1506, 1508, 1517, 1518, 1522, 1524, 1526, 1532: step; 1702: own bit; 1704: owner bit; 1706: state machine 1802, 1804, 1806, 1808: step; 1902, 1904, 1906, 1908, 1912, 1914, 1916, 1918: steps; 2002, 20 04, 2006, 2008: steps; 2202, 2203, 2204, 2205, 2206, 2208, 2212, 2214, 2216, 2218, 2222, 2224: steps; 2302, 2304, 2305, 2306, 2312, 2315, 2318, 2324: Step; 2404: kernel microcode ROM; 2408: non-core microcode patch random access memory; 2423: service processing unit; 2425: non-core microcode ROM; 2439: patch addressable content memory; 2497: service processing unit Start address scratchpad 2499: kernel random access memory; 2500: microcode patch; 2502: header; 2504: instant patch; 2506: checksum; 2508: CAM data; 2512: kernel PRAM patch; 2514: checksum ;2516: RAM Patching; 2518: Non-Core PRAM Patching; 2522: Proofsumming; , 2652: step; 2808: kernel patched RAM; 2912, 2916, 2922, 2932: step; 3002, 3004, 3006: step; 3102: memory type range scratchpad; 3202, 3204, 3206, 3208, 3211, 3212, 3214, 3216, 3218, 3252: steps.

Detailed ways

The following describes the preferred embodiment of the present invention. Each embodiment is used to illustrate the principles of the present invention, but not to limit the present invention. The scope of the present invention should be determined by the claims.

Please refer to FIG. 1 , which is a block diagram showing a multi-core microprocessor 100 . The microprocessor 100 includes a plurality of processing cores, labeled 102A, 102B to 102N, collectively referred to as the plurality of processing cores 102 , or simply the plurality of cores 102 , and individually referred to as the processing cores 102 or simply the cores 102 . More preferably, each core 102 includes a pipeline of one or more functional units (not shown in the figure), which includes an instruction cache (instruction cache), an instruction conversion unit or an instruction decoder, and more preferably includes A microcode unit, temporary renaming unit, reservation station, cache memory, execution unit, memory subsystem, and retirement unit including a sort buffer. More preferably, the plurality of cores 102 includes a superscalar, out-of-order execution microarchitecture. In one embodiment, the microprocessor 100 is an x86 architecture microprocessor, but in other embodiments, the microprocessor 100 conforms to other instruction set architectures.

The microprocessor 100 also includes an uncore 103 different from the plurality of cores 102 coupled to the plurality of cores 102 . The non-core 103 includes a control unit 104, fuses 114, a dedicated random access memory 116 (Private Random Access Memory, PRAM) and a shared cache memory 119 (Shared Cache Memory), for example, a shared by a plurality of cores 102 Second level (level-2, L2) and/or third level (level-3, L3) cache memory. Each core 102 is configured to read/write data from/to the non-core 103 via a respective address/data bus 126, and the core 102 provides a non-architectural address space (also referred to as a private or micro-architectural address space) to Uncore 103 shared resources. The dedicated random access memory 116 is dedicated or non-architectural, that is, it is not in the architectural user program address space of the microprocessor 100 . In one embodiment, the non-core 103 includes an arbitration logic (Arbitration Logic), which arbitrates requests to access resources of the non-core 103 through multiple cores 102 .

Each fuse 114 is an electronic device that can be blown or not blown; when the fuse 114 is not blown, the fuse 114 has low impedance and easily conducts current; when the fuse 114 is blown , the fuse 114 has high impedance and does not easily conduct current. A detection circuit is associated with each fuse 114 to evaluate the fuse 114, e.g., detect whether the fuse 114 conducts a high current or low voltage (not blown, e.g., logic zero, or clear) ) or a low current or high voltage (blow, eg logic one, or set). The fuse 114 can be blown during the manufacture of the microprocessor 100 , and in some embodiments, an unblown fuse 114 can be blown after the manufacture of the microprocessor 100 . More preferably, a blown fuse 114 is irreversible. An example of a fuse 114 is a polysilicon fuse that can be blown by applying a high enough voltage across the devices. Another example of a fuse 114 is a nickel-chrome fuse, which can be blown using a laser. More preferably, the sensing circuit powers on the sensing fuse 114 and provides its evaluation to a corresponding bit in the holding register (Holding Register) of the microprocessor 100 . When the microprocessor 100 is released from reset, the plurality of cores 102 (eg, microcode) read the save register to determine the value of the sensed fuse 114 . In one embodiment, before the microprocessor 100 is released from reset, the updated value may be scanned into a holding register via a boundary scan input, such as a Joint Test Action Group (JTAG), for example. , JTAG) input to substantially update the value of fuse 114. This is especially useful for testing and/or debugging purposes, as in the embodiments described below in relation to FIGS. 22 and 23 .

In addition, in one embodiment, the microprocessor 100 includes a different local Advanced Programmable Interrupt Controller (Advanced Programmable Interrupt Controller, APIC) associated with each core 102 (not shown). In one embodiment, the local Advanced Programmable Interrupt Controller architecturally complies with Intel Corporation, Santa Clara, California (Santa Clara), May 2012 in Intel 64 and IA-32 Architectures Software Developer's Handbook 3A A description of the Local Advanced Programmable Interrupt Controller, especially in Section 10.4. Especially the local advanced programmable interrupt controller includes an advanced programmable interrupt controller ID and an advanced programmable interrupt controller base address register including a bootstrap processor (Bootstrap Processor, BSP) flag, and its generation and use will be The embodiment is described in more detail below, especially in relation to FIGS. 14 to 16 .

The control unit 104 includes hardware, software, or a combination of hardware and software. The control unit 104 includes a hardware semaphore (Hardware Semaphore) 118 (described in detail in FIGS. scratchpad 108. More preferably, each uncore 103 entity is addressable by each core 102 at a different address within a non-architectural address space that enables microcode to read from and write to the core 102 .

Each synchronous register 108 is writable by a respective corresponding core 102 . State register 106 is read by each core 102 . Configuration register 112 is readable and indirectly writable by each core 102 (via disable core bit 236 of FIG. 2 as described below). The control unit 104 may also include interrupt logic (not shown in the figure), which generates a corresponding interrupt signal (interrupt signal, INTR) 124 to each core 102, which is generated by the control unit 104 to interrupt the corresponding core 102. The interrupt source responds to the control unit 104 generating an interrupt signal 124 to a core 102, and the interrupt source may include an external interrupt source (for example, an x86 architecture INTR, SMI, NMI interrupt source) or a bus event (for example, an x86 architecture-style bus signal STPCLK assertion or de-assertion). In addition, each core 102 can send an inter-core interrupt signal 124 to each other core 102 through the write control unit 104 . More preferably, unless otherwise specified, the inter-core interrupt signal described herein is a non-architectural inter-core interrupt signal requested by the microcode of a core 102 via a microinstruction (microinrstuction), which is different from the system software via a Legacy architecture intercore interrupt signal requested by an architecture instruction. Finally, when a synchronization condition (Synchronization Condition) has occurred, as described below (for example, please refer to FIG. 21 and block 334 in FIG. 3), the control unit 104 can generate an interrupt signal 124 to the core 102 (a synchronization interrupt Signal). The control unit 104 also generates a corresponding clock signal (CLOCK) 122 to each core 102, wherein the control unit 104 can selectively shut down and effectively put the corresponding core 102 to sleep and turn on to wake the core 102 for backup. The control unit 104 also generates a corresponding core power control signal (PWR) 128 to each core 102 , which selectively controls the corresponding core 102 to receive or not receive power. Therefore, the control unit 104 can selectively cause a core 102 to enter a deeper sleep state to power off the core and re-enable power to the core 102 to wake up the core 102 via the corresponding power control signal 128 .

A core 102 can write to its corresponding synchronization register 108 with a synchronization bit set (see S bit 222 in FIG. 2 ), and the above operation is regarded as a synchronization request (Synchronization Request). A more detailed description is as follows. In one embodiment, the sync request control unit 104 puts the core 102 into a sleep state and wakes up the core 102 when a sync condition occurs and/or when a specific wakeup event occurs. A synchronization condition occurs for all enabled (see enable bit 254 in FIG. 2 ) cores 102 in microprocessor 100 or a specific subset of enabled cores 102 (see core set field 228 in FIG. 2 ). ) has written the same synchronization condition (detailed in Figure 2 in a combination of C bit 224, synchronization condition or C-state field 226, and core set field 228, S bit 222 is described in more detail below) to its corresponding of the synchronous scratchpad 108. In response to the occurrence of a synchronization condition, the control unit 104 simultaneously wakes up all cores 102 that are waiting for the synchronization condition, ie, the synchronization condition has been requested. In another embodiment described below, a core 102 may request that only the last core 102 that wrote the sync request be woken up (see selective wakeup bit 214 of FIG. 2 ). In another embodiment, the sync request does not request the core 102 to go to sleep, but rather, the sync request requests that the control unit 104 interrupt the core 102 when a sync condition occurs, as described in more detail below, particularly in FIGS. 3 and 21 .

More preferably, when the control unit 104 detects that a sync condition has occurred (due to the last write of a sync request to the last core 102 in the sync register 108), the control unit 104 puts the last core 102 into a sleep state, e.g., The clock signal 122 transmitted to the last write core 102 is turned off, and then all cores 102 are woken up at the same time, eg, the clock signal 122 transmitted to all cores 102 is turned on. In this approach, all cores 102 are woken up at exactly the same clock cycles, eg, have their clock signals 122 turned on. It is especially beneficial for certain operations, such as debugging (see the embodiment in FIG. 5 ), which is beneficial for waking up the core 102 at exactly the same clock cycle. In one embodiment, the non-core 103 includes a single phase-locked loop (PLL), which generates the clock signal 122 provided to the core 102 . In other embodiments, the microprocessor 100 includes multiple phase-locked loops that generate the clock signal 122 that is provided to the core 102 .

Control, Status and Configuration Words

Please refer to FIG. 2 , which shows a block diagram of a control word 202 , a status word 242 and a configuration word 252 . A core 102 writes a value of the control word 202 to the synchronous register 108 of the control unit 104 of FIG. Cores 102, or a specific subset, are synchronized (synchronized). A core 102 reads a value of the status word 242 transmitted from the status register 106 of the control unit 104 to determine the status information described herein. A core 102 reads a value of the configuration word 252 transmitted from the configuration register 112 of the control unit 104 and uses the value, as described below.

The control word 202 includes a wakeup event field 204 , a synchronization control field 206 and a power gate (PG) bit 208 . The synchronization control field 206 includes various bits or subfields that control sleep of the core 102 and/or synchronization of the core 102 with other cores 102 . The synchronous control field 206 includes a sleep bit 212, a selective wake-up (SEL WAKE) bit 214, an S bit 222, a C bit 224, a sync state or C-state field 226, a core set field 228, A force sync bit 232 , an optional sync kill bit 234 , and a core disable core bit 236 . The status word 242 includes a wakeup event field 244 , a minimum common C-state field 246 and an error code field 248 . The configuration word 252 includes enable bits 254 for each core 102 of the microprocessor 100 , a local core number field 256 and a crystal number field 258 .

The wakeup event field 204 of the control word 202 includes a plurality of bits corresponding to different events. If the core 102 sets a bit in the wakeup event field 204, the control unit 104 will wake up the core 102 (eg, turn on the clock signal 122 to the core 102) when an event occurs corresponding to the bit. A wakeup event occurs when the core 102 has synchronized with all other cores specified in the core set field 228 . In one embodiment, the core set field 228 may specify all cores 102 in the microprocessor 100; all cores 102 share a cache (e.g., a second-level (L2) cache and and/or third-level (L3) cache); in the same semiconductor crystal, all cores 102 are real-time cores 102 (see FIG. 4 for an example of an embodiment of a multi-crystal, multi-core microprocessor 100); or in All cores 102 in other semiconductor crystals are instant cores 102 . A set of shared cache cores 102 can be regarded as a slice. Other examples of other wakeup events include, but are not limited to, an x86INTR, SMI, NMI, STPCLK assertion or de-assertion, and an inter-core interrupt. When a core 102 wakes up, it can read the wakeup event field 244 in the status word 242 to determine the active wakeup event.

If the core 102 sets the PG bit 208 , the control unit 104 puts the core 102 into a sleep state and shuts down power to the core 102 (eg, via the power control signal 128 ). When control unit 104 subsequently restores power to core 102 , control unit 104 clears PG bit 208 . The use of the PG bit 208 is described in more detail in FIGS. 11-13 below.

If the core 102 sets the sleep bit 212 or the selective wake-up bit 214 , the control unit 104 makes the core 102 enter the sleep state after the core 102 writes to the sync register 108 using the wake-up event specified in the wake-up event field 204 . The sleep bit 212 and the selective wakeup bit 214 are mutually exclusive. The difference between them is related to the action taken by the control unit 104 when a synchronization situation occurs. If the core 102 sets the sleep bit 212, the control unit 104 will wake up all the cores 102 when a synchronization situation occurs. Conversely, if a core 102 sets the selective wake-up bit 214 , when a sync condition occurs, the control unit 104 will only wake up the core 102 that last wrote the sync condition to its sync register.

If the core 102 does not set the sleep bit 212 and does not set the selective wake-up bit 214, although the control unit 104 will not cause the core 102 to enter the sleep state, when a synchronization occurs, the control unit 104 will not wake up the core 102 . The control unit 104 will still set the bit in the wakeup event field 204 indicating that a sync condition is active, so the core 102 can detect that the sync condition has occurred. A number of wakeup events that can be specified in the wakeup event field 204 can also interrupt the source of an interrupt signal generated by the control unit 104 to the core 102 . However, the microcode of the core 102 can mask the source of the interrupt if desired. Thus, when the core 102 wakes up, the microcode can read the status register 106 to determine whether a synchronization condition or a wakeup event or both have occurred.

If the core 102 sets the S bit 222, it requests the control unit 104 to synchronize in a synchronous situation. The synchronization condition is specified in some combination of the C bit 224 , the synchronization condition or C-state field 226 , and the core set field 228 . The C-state field 226 specifies a C-state value if the C bit 224 is set; the sync condition field 226 specifies a non-C-state sync condition if the C bit 224 is cleared. More preferably, the value of the sync state or C-state field 226 includes a bounded set of non-negative integers. In one embodiment, the sync condition or C-status field 226 is 4 bits. When the C bit 224 is clear (clear), a sync condition occurs when all cores 102 in a particular core set field 228 have written the same value of the S bit 222 set and the sync condition field 226 to the sync scratchpad device 108. In one embodiment, the value of the synchronization condition field 226 corresponds to a unique synchronization condition, for example, various synchronization conditions in the exemplary embodiment described below. When the C-bit 224 is set, a synchronous condition occurs in which all cores 102 in a particular core-set field 228 write to their respective S-bit 222 sets whether or not they have written the same value in that C-status field 226 to the synchronous register 108. In this case, the control unit 104 distributes (post) the lowest written value in the C-state field 226 to the lowest common C-state field 246 in the state register 106, which can be determined by a Read by the core 102 , eg, by the primary core 102 in block 908 or by the last write/selectively woken core 102 in block 1108 . In one embodiment, if the core 102 specifies a default value (e.g., all bit sets) in the synchronization condition field 226, this instructs the control unit 104 to match any synchronization condition specified by the real-time core 102 and other cores 102 Field 226 value.

If the core 102 sets the forced sync bit 232, the control unit 104 will force all ongoing sync requests to be matched immediately.

In general, if any core 102 wakes up due to a wakeup event specified in the wakeup event field 204, the control unit 104 will stop (kill) all ongoing processes by clearing the S bit 222 in the sync register 108. synchronization request. However, if the core 102 sets the selective sync abort bit 234, the control unit 104 will abort the ongoing sync request of only the cores 102 awakened by the (asynchronous condition occurrence) wakeup event.

If two or more cores 102 request synchronization under different synchronization conditions, the control unit 104 regards this as a deadlock condition. If two or more cores 102 write different values in the S bit 222 with a value set (set), the C bit 224 with a clear value, and the synchronization status field 226 into their respective synchronization registers 108 In the middle, two or more cores 102 request synchronization under different synchronization conditions. For example, if a core 102 writes an S bit 222 whose value is set (set), a C bit 224 whose value is cleared, and a value 7 of a sync condition 226 into the sync register 108, And when another core 102 writes an S bit 222 whose value is set (set), a C bit 224 whose value is cleared (clear), and a synchronization condition 226 value 9 into the synchronization register 108, the control unit 104 This is considered to be a standstill situation. In addition, if one core 102 writes a C bit 224 with a value of clear into its synchronous register 108 and another core 102 writes a C bit 224 with a value of set into its synchronous register In the device 108, the control unit 104 regards this as a stall situation. In response to a stall condition, the control unit 104 aborts all ongoing synchronization requests and wakes up all cores 102 in the sleep state. Control unit 104 also posts the value in error code field 248 of status register 106, which is a status register that can be read by core 102 to determine the cause of the stall and take appropriate action . In one embodiment, the error code 248 represents a synchronization condition written by each core 102 that enables each core to decide whether to proceed with its predetermined route of action or delay to another core 102 . For example, if one core 102 writes a sync condition to perform a power management operation (e.g., executes an x86MWAIT instruction) and another core 102 writes a sync condition to perform a cache management operation (eg, x86WBINVD instruction) , then the core 102 that plans to execute the MWAIT instruction cancels the MWAIT instruction because MWAIT is an optional operation, and WBINVD is a mandatory operation, so as to delay to another core 102 that is executing the WBINVD instruction. In another example, if one core 102 writes a sync state to perform a debug operation (eg, dump debug state) and another core 102 writes a sync state to perform a cache During a management operation (eg, a WBINVD instruction), the core 102 that plans to perform WBINVD stores the WBINVD state, waits for the dump to occur and restores the WBINVD state, and executes the WBINVD instruction to delay until the core 102 that executes the dump.

Crystal number field 258 is zero in a single crystal embodiment. In a multiple crystal embodiment (eg, in FIG. 4 ), the crystal number field 258 indicates which crystal is resident by the core 102 that reads the configuration register 112 . For example, in the one-two crystal embodiment, the crystals are designated as 0 and 1 and the crystal number field 258 has a value of 0 or 1. In one embodiment, fuse 114 is selectively blown to designate a crystal as 0 or 1, for example.

The local core count field 256 indicates the number of cores in the crystal local to the core 102 that is reading the configuration register 112 . More preferably, although there is a single configuration register 112 shared by all cores 102, the control unit 104 knows which core 102 is reading the configuration register 112, and based on a reader in the local core number field The correct value is provided in bit 256. This allows the microcode of a core 102 to know the number of local cores among other cores 102 in the same crystal. In one embodiment, a multiplexer in the non-core 103 portion of the microprocessor 100 selects the appropriate value, which may be local to the core in the configuration word 252 based on the core 102 reading the configuration register 112. Quantity field 256 is restored. In one embodiment, selectively blowing the fuse 114 operates in conjunction with the multiplexer to restore the value of the local core count field 256 . More preferably, the value of the local core number field 256 is fixed independently of which cores 102 in the crystal are available, as indicated by the enable bit 254 described below. That is, the value of the local core count field 256 remains fixed even when one or more cores 102 of the crystal are disabled. In addition, the microcode of the core 102 calculates the overall core quantity of the core 102, and the overall core quantity of the core 102 is a configuration-related value, and its usage is described in detail as follows. The overall core number indicates the core number of the overall cores 102 of the microprocessor 100 . The core 102 calculates its overall core count by using the value of the crystal count field 258 . For example, in one embodiment, the microprocessor 100 includes 8 cores 102 divided equally into two crystals having crystal values 0 and 1, in each crystal the local core count field 256 returns a 0, 1 , a value of 2 or 3; adding 4 to a core with a crystal value of 1 restores the value of the local core count field 256 to calculate its overall core count.

Each core 102 of the microprocessor 100 has a configuration word 252 corresponding to an enable bit 254, and the configuration word 252 indicates whether the core 102 is enabled or disabled. In FIG. 2 , the enable bits 254 are represented by enable bits 254 -x respectively, where x is the overall core quantity of the corresponding core 102 . The example in FIG. 2 assumes that there are eight cores 102 in the microprocessor 100. In the examples of FIGS. Enabled, the enable bit 254-1 indicates whether the core 102 with an overall core number of 1 (eg, core B) is enabled, and the enable bit 254-2 indicates whether the core 102 with an overall core number of 2 (eg, core C) is enabled enable etc. Therefore, by knowing the overall core count, the microcode of a core 102 can determine from the configuration word 252 which core 102 of the microprocessor 100 is disabled and which core 102 is enabled. More preferably, if the core 102 is enabled, the enable bit 254 is set, and if the core 102 is disabled, the enable bit 254 is cleared. When the microprocessor 100 is reset, hardware automatically populates the enable bit 254 . More preferably, when the microprocessor 100 is manufactured to indicate whether a given core 102 is enabled or disabled, the hardware populates the enable bit 254 based on the fuse 114 being selectively blown. For example, if a given core 102 is tested and found to be faulty, a fuse 114 may be blown to clear the enable bit 254 for that core 102 . In one embodiment, a blown fuse 114 indicates a core 102 is disabled and prevents clock signals from being provided to the disabled core 102 . Each core 102 can write the disable core bit 236 into its synchronous register 108 to clear its enable bit 254. More details related to FIGS. 14-16 are described below. More preferably, clearing enable bit 254 will not prevent the core 102 from executing instructions, but will update the configuration register 112, and the core 102 must set a different bit (not shown) to prevent The core itself executes instructions, for example, to have its power removed and/or its clock signal turned off. For a multi-crystal configuration microprocessor 100 (e.g., FIG. 4), the configuration register 112 includes uniform enable bits 254 for all cores 102 in the microprocessor 100, e.g., all cores 102 may not only be cores of the local crystal 102, and may also be the nucleus 102 of the distal crystal. More preferably, in a multi-crystal microprocessor 100, when a core 102 writes to its sync register 108, the value of the sync register 108 is passed to the corresponding shadow sync register in the other crystal. The core 102 of the register 108 (see FIG. 4 ), wherein, if the disable core bit 236 is set, will cause an update to be sent to the remote crystal configuration register 112 so that the local and remote crystal configuration temporary The registers 112 all have the same value.

In one embodiment, the configuration register 112 cannot be directly written by a core 102 . However, writing to the configuration register 112 by a core 102 will cause the value of the local enable bit 254 to be propagated to the configuration registers 112 of other crystals in a multi-crystal microprocessor 100, for example, as shown in FIG. 14 described in block 1406.

control unit

Please refer to FIG. 3 , which shows a flowchart describing the control unit 104 . Flow begins at block 302 . In block 302 , a core 102 writes a synchronization request, eg, a control word 202 , into its synchronization register 108 , wherein the synchronization request is received by the control unit 104 . In the case of a multi-crystal configuration microprocessor 100 (see, for example, FIG. , the control unit 104 effectively operates according to FIG. 3, for example, when the control unit 104 receives a synchronization request from one of its local cores 102 (block 302), except that the control unit 104 puts the core 102 into sleep (e.g., block 302). 314), or wake up (at blocks 306, 328, or 336), or interrupt (at block 334), or prevent core 102 from waking up events (block 326) at its local crystal 406, and also populate its local state register 106 (block 318). Flow proceeds to block 304 .

In block 304, the control unit 104 checks the synchronization condition in block 302 to determine whether a deadlock condition has occurred, as described above in FIG. 2 . If yes, the process proceeds to block 306 ; otherwise, the process proceeds to decision block 312 .

In block 305, the control unit 104 detects the occurrence of a wake-up event in the wake-up event column 204 of one of the synchronization registers 108 (in addition to the occurrence of a sync condition detected in block 316) . As described in block 326 below, the control unit 104 may automatically prevent the wake-up event. The control unit 104 may write a synchronization request in block 302 when detecting that the wakeup event occurs as an event asynchronous (Event Asynchronous). The process also proceeds from block 305 to block 306 .

In block 306 , the control unit 104 fills the status register 106 , aborts the ongoing synchronization request, and wakes up any sleeping cores 102 . As noted above, waking the sleeping core 102 may include restoring its power. The core 102 can then read the status register 106, particularly the error code 248, to determine the cause of the stall, and process it according to the corresponding priority of the conflicting sync request, as described above. In addition, the control unit 104 aborts all ongoing synchronization requests (e.g., clears the S bit 222 in the synchronization register 105 of each core 102), unless block 306 is reached after block 305 and the selective synchronization is terminated When bit 234 is set, in this case, the control unit 104 will abort the ongoing synchronization request of only the cores 102 awakened by the wakeup event. If block 306 is achieved after block 305, the core 102 can read the wakeup event 244 field to determine the wakeup event that occurred. In addition, if the wakeup event is an unmasked interrupt source, the control unit 104 will generate an interrupt request to the core 102 through the interrupt signal 124 . Flow ends in block 306 .

In decision block 312, the control unit 104 determines whether the sleep bit 212 or the selective wakeup bit 214 is set. If yes, the flow proceeds to block 314 ; otherwise, the flow proceeds to decision block 316 .

In block 314, the control unit 104 puts the core 102 into a sleep state. As noted above, putting a core 102 to sleep may include removing its power source. In one embodiment, as an optimized example, even if the PG bit 208 is set, if this is the last core 102 written to (e.g., would cause a synchronous condition to occur), in block 314, the control Unit 104 does not remove power to the core 102 and since the control unit 104 will immediately wake up the last written core 102 backup in block 328 , the selective wakeup bit 214 is set. In one embodiment, the control unit 104 includes a sync logic and a sleep logic, which are separate from each other but communicate with each other; in addition, each of the sync logic and sleep logic includes a part of the sync register 108 . Advantageously, the sync logic portion written to the sync register 108 and the sleep logic portion written to the sync register 108 are atomic, ie indivisible. That is, if a portion of the write occurs, both the sync logic and the sleep logic are guaranteed to occur. More preferably, the pipeline of the core 102 is blocked, not allowing any more writes to occur until both parts of its guaranteed write to the sync register 108 have occurred. An advantage of writing a sync request and immediately going to sleep is that it does not require the core 102 (eg, microcode) to run continuously to determine whether the sync condition has occurred. This is beneficial because it saves power and does not consume other resources, such as bus and/or memory bandwidth. It is worth noting that, in order to enter the sleep state but without requesting synchronization with other cores 102 (for example, block 924 and block 1124), the core 102 can write the S bit 222 to clear (Clear) and the sleep bit 212 to set (Set ), referred to herein as a sleep request, to the sync register 108; if an unmasked wakeup event specified in the wakeup event field 204 occurs (e.g., block 305), but does not look for the core 102 when a synchronization condition occurs (eg, block 316 ), in which case the control unit 104 wakes up the core 102 (eg, block 306 ). Flow proceeds to decision block 316 .

In decision block 316, the control unit 104 determines whether a synchronization condition occurs. If yes, the process proceeds to block 318 . As mentioned above, a synchronous condition can only occur when the S bit 222 is set. In one embodiment, the control unit 104 uses the enable bit 254 in FIG. 2 , which indicates which cores 102 in the microprocessor 100 are enabled and which cores 102 are disabled. The control unit 104 only looks for the enabled cores 102 to determine whether a synchronization condition occurs. A core 102 may be disabled because it was tested and found to be defective during production time. Accordingly, a fuse is blown to disable the core 102 and indicate that the core 102 is disabled. A core 102 may be disabled due to software requested by the core 102 (eg, see FIG. 15 ). For example, when a user requests, the BIOS writes a special module register (Model Specific Register, MSR) to request that the core 102 be disabled, in response to the core 102 stopping using itself (for example, by The disable core bit 236 ), and notify other cores 102 to read the configuration register 112 that other cores 102 decide to disable the core 102 . A core 102 can also be patched via a microcode (eg, see FIG. 14 ) that can be generated by blowing a fuse 114 and/or loaded from system memory (eg, a FLASH memory). In addition to determining whether a sync condition occurs, the control unit 104 checks the forced sync bit 232 . If it is set (set), the process proceeds to block 318 . If the forced sync bit 232 is clear and a sync condition has not occurred, the process ends at block 316 .

In block 318 , the control unit 104 populates the state register 106 . Specifically, the control unit 104 fills the lowest common C-state field 246 if a synchronization condition occurs that requests a C-state synchronization for all cores 102 , as described above. Flow proceeds to decision block 322 .

In decision block 322 , the control unit 104 checks the SEL WAKE bit 214 . If the bit is set, the process proceeds to block 326 ; otherwise, the process proceeds to decision block 322 .

In block 326, the control unit 104 prevents all wake-up events of all other cores 102 except the instant core, which is the core that wrote the sync request to its sync register 108 last in block 302 102, thus causing this synchronization condition to occur. In one embodiment, the logic of the control unit 104 simply performs a Boolean AND operation with a wakeup condition that is a False signal if the wakeup event to be prevented and other aspects are true. The use of blocking all wakeup events for all cores is described in more detail below, particularly FIGS. 11-13 . Flow proceeds to block 328 .

In block 328, the control unit 104 wakes up only the immediate core 102, but not other cores requesting the synchronization. In addition, the control unit 104 aborts the ongoing sync request of the immediate core 102 by clearing the S bit 222 , but does not abort the ongoing sync request of other cores 102 , eg, leaving the S bit 222 of the other core 102 set. It is therefore advantageous if when an instant core 102 writes another sync request after it wakes up, it will cause the sync situation to happen again (assuming the sync requests of other cores 102 have not been aborted), an example will be below Described in Figure 12 and Figure 13. Flow ends at block 328 .

In decision block 332 , the control unit 104 checks the sleep bit 212 . If the bit is set, flow proceeds to block 336 ; otherwise, flow proceeds to block 334 .

In block 334 , the control unit 104 sends an interrupt signal (synchronous interrupt) to all cores 102 . FIG. 21 is a timing diagram illustrating an example of a non-sleep sync request. Each core 102 can read the wakeup event field 244 and detect the occurrence of a synchronous condition as the cause of the interrupt. Flow has proceeded to block 334, in which case core 102 chooses not to go to sleep when core 102 writes its sync request. While this situation does not give the cores 102 the same benefits as going to sleep (e.g., simultaneous wakeup), it has the advantage of allowing the cores 102 to wait for the cores 102 to finally write their synchronization requirements without simultaneous wakeup. Potential advantages of continuing to process instructions. Flow ends at block 334 .

In block 336, the control unit 104 is woken up by all cores 102 simultaneously. In one embodiment, the control unit 104 accurately turns on the clock signal 122 to all cores 102 at the same clock cycle. In another embodiment, the control unit 104 enables the clock signal 122 to all cores 102 in a staggered manner. That is, the control unit 104 introduces a predetermined number of clock cycles (eg, a clock sequence of ten or one hundred) between the turn-on clock signal 122 to each core. However, staggering on of the clock signal 122 is also contemplated in the present invention. To reduce the possibility of a power consumption spike when all cores 102 wake up, it is beneficial to stagger the clock signal 122 on. In yet another embodiment, to reduce the possibility of power loss spikes, the control unit 104 turns on the clock signal 122 to all cores 102 on the same clock cycle, but by initially providing the clock at a reduced frequency Signal 122 and boost frequency to below the target frequency, performed in a stuttering, or throttled, manner. In one embodiment, the synchronization request is issued as a result of execution of microcode instructions of the core 102, and the microcode is designed for at least some synchronization condition values, and the microcode location specifying the synchronization condition values is unique of. For example, there is only one place in the microcode that includes a synchronous x request, only one place in the microcode that includes a synchronous y request, and so on. In these cases, simultaneous wakeup is beneficial because all cores 102 wake up at exactly the same place, which allows microcode designers to design more efficient and bug-free program code. Also, simultaneous wakeup for debugging purposes can be particularly beneficial when attempting to re-establish and fix errors due to multi-core interaction, but not when a single core is running. Figures 5 and 6 show such an example. In addition, the control unit 104 aborts all ongoing sync requests (eg, clears the S bit 222 in the sync register 108 of each core 102). Flow ends at block 336 .

An advantage of the embodiments described herein is that it can significantly reduce the amount of microcode in a microprocessor, because the microcode in each core can Simply write a synchronous request to go to sleep and know when to wake up all cores in the same place in the microcode. The microcode usage of the synchronous request mechanism is described below.

polycrystalline microprocessor

Please refer to FIG. 4 , which is a block diagram showing another embodiment of a microprocessor 100 . Microprocessor 100 in FIG. 4 is similar in many respects to microprocessor 100 in FIG. 1 , where a multi-core processor and cores 102 are similar. However, the embodiment of Figure 4 is a polycrystalline configuration. That is, the microprocessor 100 includes multiple semiconductor crystals 406 mounted in a common package and communicating with one another via an intra-crystal bus 404 . The embodiment of FIG. 4 includes two crystals 406 , labeled crystal A 406A and crystal B 406B coupled by an inter-crystal bus 404 . In addition, each crystal 406 includes an inter-crystal bus unit 402 that connects the respective crystal 406 to the inter-crystal bus 404 . Furthermore, each crystal 406 includes the control unit 104 in the non-core 103 coupled to the respective core 102 and the inter-crystal bus unit 402 . In the embodiment of FIG. 4, crystal A 406A includes four cores 102—core A 102A, core B 102B, core C 102C, and core D 102D—wherein the four cores 102 are coupled to an inter-crystal bus unit Control unit A 104A of A 402A; likewise, crystal B 406B includes four cores 102—core E 102E, core F 102F, core G 102G, and core H 102H, wherein the four cores 102 are coupled to an inter-crystal coupling Control unit B 104B of bus unit B 402B. Finally, each control unit 104 includes not only a synchronous register 108 for each core in the crystal 406 including itself, but also a synchronous register 108 for each core in the other crystal 406, wherein the other The synchronous register 108 in a crystal 406 is a shadow register shown in FIG. 4 . Accordingly, each control unit in the embodiment shown in FIG. 4 includes eight synchronous registers 108, indicated as 108A, 108B, 108C, 108D, 108E, 108F, 108G, and 108H. In control unit A 104A, sync registers 108E, 108F, 108G, and 108H are shadow registers, and in control unit B 104B, sync registers 108A, 108B, 108C, 108D are shadow registers.

When a core 102 writes a value into its synchronous register 108, the control unit 104 in the crystal 406 of the core 102 writes the value to the other crystal via the inter-crystal bus unit 402 and the inter-crystal bus 404. 406 corresponds to the shadow register 108. Additionally, the control unit 104 also updates the corresponding enable bit 254 in the configuration register 112 if the disable core bit 236 is set in the value propagated to the shadow sync register 108 . In this manner, even in situations where the microprocessor 100 core configuration is dynamically changing (eg, FIGS. 14-16 ), the occurrence of a synchronization condition (including the occurrence of a trans-die synchronization condition) ) can be detected. In one embodiment, the inter-crystal bus 404 is a relatively low-speed bus, and the propagation may take a predetermined number of clock cycles in the order of 100 cores, and each control unit 104 includes a state machine that takes a predetermined number of time to detect the occurrence of the synchronous condition and turn on the clock signal to all cores 102 in the respective crystal 406 . More preferably, after a control unit 104 begins writing values to another crystal 406 (e.g., the granted inter-crystal bus 404), the control unit 104 in the local crystal 406 (e.g., the crystal that includes the write core 102 406) configured to defer updating the local synchronization register until a predetermined amount of time (eg, the sum of the amount of propagation time and the amount of time the state machine synchronization situation has been detected). In this way, the control unit 104 in both crystals simultaneously detects the occurrence of a synchronization condition and turns on the clock signals to all cores 102 in both crystals 406 at the same time. It may be particularly beneficial for debugging purposes when attempting to recreate and fix errors that occur only due to multi-core interaction, but not while a single core is running. Figures 5 and 6 describe embodiments that may take advantage of this functionality.

debug operation

The core 102 of the microprocessor 100 is configured to perform individual adjustment operations, such as breakpoints for instruction execution and data access. Additionally, the microprocessor 100 is configured to perform debug operations that are trans-core, eg, the debug operations are associated with more than one core 102 of the microprocessor 100 .

Please refer to FIG. 5 , which is a flowchart showing the operation of the microprocessor 100 to dump debug information. The operation is described from the perspective of a single core, but each core 102 in the microprocessor 100 collectively dumps the state of the microprocessor 100 according to its described operation. More specifically, FIG. 5 describes the operation of one core receiving a request to dump debug information, its flow starts at block 502 , and the operation flow of other cores 102 starts at block 532 .

In block 502, one of the cores 102 receives a request to dump debug information. More preferably, the adjustment information includes the state of the core 102 or a subset thereof. More preferably, tuning information is dumped to system memory or an external bus that can be monitored by tuning equipment, such as a logic analyzer. In response to the request, the core 102 sends a debug dump message to the other core 102 and sends the other core 102 an inter-core interrupt signal. More preferably, during this time that interrupts are disabled (e.g., the microcode is not allowed to be interrupted itself), the core 102 blocks the microcode from responding to the request to dump debug information (in block 502), or Respond to the aforementioned interrupt signal (at block 532 ) and remain in microcode until block 528 . In one embodiment, the core 102 only needs to interrupt when it is asleep and at an architectural instruction boundary. In one embodiment, various inter-core messages described herein (such as in block 502 and others such as in blocks 702, 1502, 2606, and 3206) control the synchronization of words via the sync register 108 Or C-status field 226 is sent and received. In other embodiments, the inter-core information is transmitted and received via the non-core dedicated RAM 116 . Flow proceeds from block 502 to block 504 .

In block 532, one of the other cores 102 (e.g., a core 102 other than the core 102 receiving the debug dump request in block 502) is interrupted due to the inter-core interrupt signal and information transmitted in block 502 and Receive the debug dump information. As noted above, although the flow in block 532 is described from the perspective of a single core 102, each other core 102 (eg, a core 102 not in block 502) is interrupted at block 532 and receives this information, and executes block 532. Steps 504 to 528. Flow proceeds from block 532 to block 504 .

In block 504 , the core 102 writes a sync request into its sync register 108 for a sync case 1 (labeled SYNC 1 in FIG. 5 ). Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 506 .

In block 506 , core 102 is woken up by control unit 104 when all cores have written to SYNC 1 . Flow proceeds to block 508 .

In block 508, the core 102 dumps its state to memory. Flow proceeds to block 514 .

In block 514, the core 102 writes a SYNC 2, which causes the control unit 104 to put the core 102 into a sleep state. Flow proceeds to block 516 .

In block 516 , core 102 is woken up by control unit 104 when all cores have written SYNC 2 . Flow proceeds to block 518 .

In block 518, the memory address at which the core 102 dumped the debug information in block 508 sets a flag, asserts it through a reset signal, and then resets itself. Core 102 resets the microcode, which detects the flag and reloads its state from the stored memory address. Flow proceeds to block 524 .

In block 524, the core 102 writes a SYNC 3, which causes the control unit 104 to put the core 102 into a sleep state. Flow proceeds to block 526 .

In block 526 , core 102 is woken up by control unit 104 when all cores have written SYNC 3 . Flow proceeds to block 528 .

In block 528, the core 102 removes reset based on the state reloaded in block 518 and begins fetching architecture (eg, x86) instructions. Flow ends at block 528 .

Please refer to FIG. 6 , which is a timing diagram showing an exemplary operation of the microprocessor 100 according to the flowchart in FIG. 5 . In this example, the microprocessor 100 is configured with three cores 102, labeled Core 0, Core 1, and Core 2, as shown. However, it should be appreciated that in other embodiments, the microprocessor 100 may include a different number of cores 102 . In this timing diagram, the process of event timing is as follows.

Core 0 receives a debug dump request, and sends a debug dump message and interrupt message to Core 1 and Core 2 (each block 502 ) in response. The core 0 then writes a SYNC 1 and goes to sleep (per block 504).

Each core 1 and core 2 is finally interrupted from its current task and reads its information (each block 532). In response, Core 1 and Core 2 each write a SYNC 1 and go to sleep (per block 504). As shown, each core may write to SYNC 1 at a different time, eg, because the instruction was executing when the interrupt was asserted.

When all cores have written SYNC 1, control unit 104 wakes up all cores simultaneously (per block 506). Each core then dumps its state to memory (per block 508), writes a SYNC 2 and goes to sleep (per block 514). The amount of time required to dump this state may vary; therefore, the time at which SYNC 2 is written may vary on each core, as shown.

When all cores have written SYNC 2, control unit 104 wakes up all cores simultaneously (per block 516). Each core then resets itself and reloads its state from memory (per block 518), writes SYNC 3 and goes to sleep (per block 524). As shown, the amount of time required to reset and reload state may vary; therefore, the time to write SYNC 3 may vary on each core.

When all cores have written SYNC 3, control unit 104 wakes up all cores simultaneously (per block 526). Each core then begins fetching architectural instructions at the point in time it was interrupted (each block 528).

The traditional solution to synchronize operations between multiple processors is to use software semaphores (semaphore). However, the disadvantage of the traditional solution is that it cannot provide clock-level synchronization. An advantage of the embodiments described herein is that the control unit 104 can turn on the clock signal 122 to all cores 102 at the same time.

In the method described above, an engineer tuning microprocessor 100 may configure one of cores 102 to periodically generate checkpoints for generating debug dump requests, for example, at a predetermined number of after the instruction has been executed. While the microprocessor 100 is running, the engineer captures all activity on the external bus of the microprocessor 100 in a log file. Portions of the log file for when the proximity bus is perceived to have occurred may be provided to a software simulator that simulates the microprocessor 100 to aid engineers in debugging. The simulator simulates the execution of instructions directed by each core 102 and the execution of the bus usage log information of the external microprocessor 100 . In one embodiment, the emulators for all cores 102 are started from a reset point simultaneously. Therefore, it is of high effect that all cores 102 of the microprocessor 100 actually stop reset at the same time (eg, after SYNC 2). Furthermore, dumping its state by one core 102 does not perform debugging (e.g., shared Memory bus or cache interfering) program code and/or hardware interfering with each other, which can increase the likelihood of reproducing the error and determining its cause. Likewise, waiting to start fetching architectural instructions until all cores 102 have finished reloading their state (e.g., after SYNC 3), reloading state by one core 102 will not execute debug code and and/or the hardware interferes with each other, which can increase the likelihood of reproducing the error and determining its cause.

These benefits provide advantages over existing approaches, such as US Pat. No. 8,370,684, which is hereby incorporated by reference in its entirety for all purposes, which do not enjoy the benefit of being able to obtain this synchronous requesting core.

cache control operation

The cores 102 of the microprocessor 100 are configured to perform independent cache control operations, such as in local caches, eg, caches that are not shared by two or more cores 102 . In addition, the microprocessor 100 is configured to perform cache control operations that are trans-core, for example, associated with more than one core 102 of the microprocessor 100, and for example, because of its connection with a shared cache memory 119 related.

Please refer to FIGS. 7A-7B , which are flowcharts showing the microprocessor 100 performing cross-core cache control operations. 7A-7B illustrate how the microprocessor 100 executes an x86 architecture Write Back and Invalidate Cache (WBINVD) instruction. A WBINVD instruction instructs the core 102 executing the instruction to write back all modified lines in the cache memory of the microprocessor 100 to the system memory and invalidate, or flush, the cache memory. The WBINVD instruction also instructs the core 102 to issue a special bus cycle to point any cache memory externally directly into the microprocessor 100 to write back its modified data and to invalidate said data. The above operation is described from the perspective of a single core, but each core 102 of the microprocessor 100 operates according to this specification to jointly write back the modified cache line (Modified cache line) and invalidate the cache memory of the microprocessor 100 . More specifically, FIGS. 7A-7B describe the operation of one core encountering a WBINVD instruction, whose flow begins at block 702 , and whose flow begins at block 752 for the other core 102 .

In block 702, one of the cores 102 encounters a WBINVD instruction. In response, the core 102 sends a WBINVD command message to the other core 102 and sends an inter-core interrupt signal to the other core 102 . More preferably, until the flow proceeds to block 748/749, the core 102 blocks the microcode as a response to the WBINVD instruction during the period in which the time interrupt signal is disabled (e.g., the microcode does not allow itself to be interrupted). (in block 702), or in response to the interrupt signal (in block 752), and maintained in microcode. Flow proceeds from block 702 to block 704 .

In block 752, one of the other cores 102 (e.g., a core other than the WBINVD instruction core 102 encountered in block 702) is interrupted due to the inter-core interrupt signal transmitted in block 702 and Receive the WBINVD command information. As noted above, although flow is described at block 752 from the perspective of a single core 102, each other core 102 (e.g., not the core 102 at block 702) is interrupted at block 752 and receives the information, and The steps from block 704 to block 749 are performed. Flow proceeds from block 752 to block 704 .

In block 704 , the core 102 writes a sync request for sync case 4 (labeled SYNC4 in FIGS. 7A-7B ) into its sync register 108 . Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 706 .

In block 706, when all cores 102 have written to SYNC 4, the cores 102 are woken up by the control unit 104. Flow proceeds to block 708 .

In block 708 , the core 102 writes back and invalidates a local cache, eg, a Level-1 (L1 ) cache that is not shared by the core 102 with other cores 102 . Flow proceeds to block 714 .

In block 714, the core 102 writes a SYNC 5, which causes the control unit 104 to put the core 102 into a sleep state. Flow proceeds to block 716.

In block 716 , cores 102 are woken up by control unit 104 when all cores 102 have written SYNC 5 . Flow proceeds to decision block 717.

In decision block 717, the core 102 determines whether it is the core 102 that encountered the WBINVD instruction in block 702 (as opposed to the core 102 that received the WBINVD instruction information in block 752). If so, the process proceeds to block 718 ; otherwise, the process proceeds to block 724 .

In block 718 , the core 102 writes back and invalidates the shared cache 119 . In one embodiment, the microprocessor 100 includes multiple chips in multiple cores, but not all cores, and the cores 102 of the microprocessor 100 share a cache, as described above. In this embodiment, an intermediate operation (not shown) similar to that in blocks 717 to 726 is performed, which is to perform a writeback and invalidate the shared buffer memory by one of the cores 102 on the chip that The other core(s) go back to a sleep state similar to block 724 to wait until the cache is invalidated. Flow proceeds to block 724 .

In block 724, the core 102 writes a SYNC 6, which causes the control unit 104 to put the core 102 into a sleep state. Flow proceeds to block 726.

In block 726 , cores 102 are woken up by control unit 104 when all cores 102 have written SYNC 6 . Flow proceeds to decision block 727.

In decision block 727, the core 102 determines whether it is the core 102 that encountered the WBINVD instruction in block 702 (as opposed to the core 102 that received the WBINVD instruction information in block 752). If so, the process proceeds to block 728 ; otherwise, the process proceeds to block 744 .

In block 728, the core 102 issues a specific bus cycle to cause the external cache to be written back and invalidate the external cache. Flow proceeds to block 744 .

In block 744, a SYNC 13 is written, which causes the control unit 104 to put the core 102 into a sleep state. Flow proceeds to block 746.

In block 746 , cores 102 are woken up by control unit 104 when all cores 102 have written to SYNC 13 . Flow proceeds to decision block 747.

In decision block 747, the core 102 determines whether it is the core 102 that encountered the WBINVD instruction in block 702 (as opposed to the core 102 that received the WBINVD instruction information in block 752). If so, the process proceeds to block 748; otherwise, the process proceeds to block 749.

In block 748, the core 102 completes the WBINVD instruction, which includes a retired WBINVD instruction, and may include relinquishing ownership of a hardware semaphore (see FIG. 20). Flow ends at block 748.

At block 749 , the core 102 resumes at block 749 the task 102 it was executing before the core 102 was interrupted at block 752 . Flow ends at block 749.

Referring to FIG. 8 , it is a timing diagram showing the operation of the microprocessor 100 according to the flowcharts of FIGS. 7A-7B . In this example, the microprocessor 100 is configured with three cores 102, labeled Core 0, Core 1, and Core 2, as shown. However, it should be appreciated that in other embodiments, the microprocessor 100 may include a different number of cores 102 .

Core 0 encounters a WBINVD command and sends a WBINVD command message in response, and interrupts core 1 and core 2 (each block 702). Core 0 then writes a SYNC 4 and goes to sleep (per block 704).

Each core 1 and core 2 is finally interrupted from its current task and reads the information (each block 752). In response, Core 1 and Core 2 each write a SYNC 4 and go to sleep (each block 704). As shown, each core may write to SYNC 4 at different times.

When all cores have written SYNC 4, control unit 104 wakes up all cores simultaneously (per block 706). Each core then writes back and invalidates its particular cache (per block 708), writes SYNC 5 and goes to sleep (per block 714). The amount of time required to write back and invalidate the cache may vary, so the time to write to SYNC 5 may vary on each core, as shown.

When all cores have written SYNC 5, control unit 104 wakes up all cores simultaneously (per block 716). Only the core encountering the WBINVD instruction writes back and invalidates the shared cache 119 (per block 718), and all cores write to SYNC 6 and go to sleep (per block 724). Since only one core writes back and invalidates the shared cache 119, the time each core writes to SYNC 6 may be different.

When all cores have written SYNC 6, control unit 104 wakes up all cores simultaneously (per block 726). Only the core that encountered the WBINVD instruction completes the WBINVD instruction (per block 748), and all other cores resume pre-interrupt processing.

It should be appreciated that while embodiments have been described where the cache control instruction is an x86WBINVD instruction, other embodiments may assume that synchronization requests are used to execute other cache instructions. For example, microprocessor 100 may perform similar actions so that instead of writing back cached data (at blocks 708 and 718 ), it executes an x86 INVD instruction and simply invalidates the cache. As another example, cache control instructions are available from a different instruction set architecture than the x86 architecture.

Power Management Operations

The core 102 of the microprocessor 100 is configured to perform various power-reducing operations, such as, but not limited to, stopping execution of instructions, requesting the control unit 104 to stop sending clock signals to the core 102, requesting the control unit 104 to be removed from the powers up the core 102 , writes back and invalidates the core 102's local (eg, non-shared) cache memory and stores the core 102 state to an external memory, such as dedicated random access memory 116 . A core 102 has entered a "core" C-state (also known as a core idle state or core sleep state) when it has performed one or more core-specified power reduction operations. In one embodiment, the C-state value may roughly correspond to a known Advanced Configuration and Power Interface (ACPI) specification processor state, but may also include a finer granularity (Granularity). Generally, a core 102 will enter a core C-state in response to a request from the aforementioned operating system. For example, the x86 Architecture Monitor Wait (MWAIT) instruction is a power management instruction that provides a hint, i.e., a target C-state, to the core 102 executing the instruction to allow the microprocessor 100 to enter an optimized state, such as is a lower power consumption state. In the case of a MWAIT instruction, the target C-state is proprietary rather than an ACPI C-state. Core C-state 0 (C0) corresponds to an operational state of core 102 and increasing values of C-states correspond to progressively decreasing active or responsive states (eg, C1 , C2, C3, etc. states). A progressively less responsive or active state refers to a configuration or operating state that saves more power than a more active or responsive state, or that is relatively less responsive for some reason (e.g., with a longer wakeup delay, less fully enabled). Examples of possible power-saving operations by a core 102 are stopping execution of instructions, stopping sending clock signals, reducing voltage, and/or removing power to portions of the core (e.g., functional units and/or local caches) or to the entire core .

Additionally, microprocessor 100 is configured to perform cross-core power reduction operations. The cross-core power reduction operation involves or affects multiple cores 102 of the microprocessor 100 . For example, shared cache memory 119 may be large and consume a relatively large amount of power. Thus, significant power savings can be achieved by removing clock signals and/or power to the shared cache memory 119 . However, in order to remove clock and/or power to the shared cache 119, all cores 102 sharing the cache must agree so that data coherency is maintained. Embodiments contemplate that the microprocessor 100 includes other shared power related resources, such as shared clock and power. In one embodiment, the microprocessor 100 is coupled to a system chipset including a memory controller, peripheral controller and/or power management controller. In other embodiments, one or more controllers are integrated into the microprocessor 100 . System power saving can be achieved by the microprocessor 100 notifying the controller to make the controller take power saving actions. For example, the microprocessor 100 may notify the controller to invalidate and shut down the microprocessor's cache memory so that it does not need to be detected.

In addition to the concept of a core C-state, microprocessor 100 generally has a "package" C-state (also known as a package idle state or package sleep state). The package C-state corresponds to the lowest (eg, highest power consumption) common core C-state of the core 102 (see, eg, column 246 in FIG. 2 and block 318 in FIG. 3 ). However, in addition to core-specific power reduction operations, package C-states involve the microprocessor 100 performing one or more cross-core power reduction operations. Examples of cross-core power-saving operations associated with package C-states include disabling a Phase-locked-loop (PLL) that generates a clock signal, clearing the shared cache memory 119, and stopping its clock and/or or a power supply that keeps the memory/external controller from snooping the microprocessor's 100 local shared cache memory. Other examples are changing the voltage, frequency and/or bus clock ratio, reducing the size of a cache, such as the shared cache 119, and running the shared cache 119 at half the speed.

In many cases, the operating system is effectively used to execute instructions in the individual cores 102, and thus may put the individual cores to sleep (e.g., to a core C-state), but does not have the ability to directly put the microprocessor 100 into Ways to sleep state (eg, to package C-state). Beneficially, in the embodiment described the cores 102 of the microprocessor 100 work cooperatively with each other with the help of the control unit 104 to detect when all the cores 102 have entered a core C-state and are ready to allow cross-core power saving operations to occur .

Please refer to FIG. 9 , which is a flowchart showing the operation of the microprocessor 100 entering a low power package C-state. The embodiment of FIG. 9 depicts an example where the microprocessor 100 is coupled to a chipset and executed using the MWAIT instruction. However, it should be understood that in other embodiments, the operating system uses other power management instructions and the main core 102 communicates with the controller integrated into the microprocessor 100, and uses a different handshake (Handshake) protocol to describe.

This operation is described from the perspective of a single core, but each core 102 of the microprocessor 100 may encounter the MWAIT instruction and operate according to this specification to make the microprocessor 100 enter the optimal state. Flow begins at block 902 .

In block 902, a core 102 encounters a MWAIT instruction specifying a target C-state, denoted Cx in FIG. 9, where x is a non-negative integer value. Flow proceeds to block 904 .

In block 904 , the core 102 writes a sync request to its sync register 108 with a set of C bits 224 and a C-status field 226 value of x (labeled SYNC Cx in FIG. 9 ). Additionally, the sync request specifies in its wakeup event field 204 that the core 102 wakes up on all wakeup events. Therefore, the control unit 104 puts the core 102 into a sleep state. More preferably, before the core 102 writes to SYNC Cx, the core 102 first writes back and invalidates the local cache it wrote to. Flow proceeds to block 906.

In block 906, the cores 102 are woken up by the control unit 104 when all cores 102 have written a SYNC Cx signal. As noted above, the x values written by other cores 102 may be different, and the control unit 104 sends the lowest common C-state value into the lowest common C-state field 246 of the status word 242 of the state register 106 (per block 318). Prior to block 906, while core 102 was in sleep state, it may be awakened by a wakeup event, such as an interrupt signal (eg, blocks 305 and 306). More specifically, but without guaranteeing that the operating system will execute the MWAIT instruction for all cores 102, it may allow the microprocessor 100 to effectively cancel the MWAIT instruction before a wake-up event occurs (e.g., an interrupt) that instructs one of the cores 102 to effectively cancel the MWAIT instruction. Performs power saving operations related to package C-states. However, in block 906, once the core 102 is woken up, during the period when the clock interrupt is disabled (e.g., the microcode does not allow itself to be interrupted), the core 102 (in fact, all cores 102) due to (in the block 902) the MWAIT instruction still executes the microcode and remains in the microcode until block 924. In other words, although a small number of all cores 102 have received the MWAIT instruction to enter the sleep state, individual cores 102 may be in the sleep state, but the microprocessor 100 as a package will not indicate to the die set that it is ready to enter a sleep state. Encapsulates the sleep state. However, once all cores 102 have agreed to enter a package sleep state, which is effectively indicated by the occurrence of a synchronization condition in block 906, the primary core 102 is allowed to complete a package sleep state handshake protocol with the chipset (e.g., blocks 908, 909 and following 921), and are not interrupted and none of the other cores 102 are interrupted. The process proceeds to decision block 907 .

In decision block 907 , the core 102 determines whether it is the primary core 102 of the microprocessor 100 . More preferably, one core 102 is the primary core 102 if it is determined to be the BSP at the reset time. If the core is the primary core, the process proceeds to block 908 ; otherwise, the process proceeds to block 914 .

In block 908, the primary core 102 writes back and invalidates the shared cache memory 119, then communicates with the chipset that it can take appropriate action to reduce power consumption. For example, the memory controller and/or the external controller can avoid probing the local and shared cache memory. As another example, the chipset may transmit signals to the microprocessor 100 to cause the microprocessor 100 to take power-saving operations (eg, assert x86-style STPCLK, SLP, DPSLP, NAP, VRDSLP signals as described below). More preferably, the core 102 communicates power management information based on the lowest common C-state field 246 value. In one embodiment, the core 102 issues an I/O read bus cycle to an I/O address that provides chipset-related power management information, eg, package C-state values. The flow goes to block 909.

In block 909, the primary core 102 waits for the chipset to assert the STPCLK signal. More preferably, if the STPCLK signal is not asserted after a predetermined number of bright clock cycles, the control unit 104 detects this situation after suspending its ongoing synchronization request, wakes up all cores 102 and displays an error message in the error code column. The error is indicated in bit 248. Flow proceeds to block 914.

In block 914, the core 102 writes a SYNC 14. In one embodiment, the sync request specifies in its wakeup event field 204 that the core 102 has not been woken up in any wakeup event. Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 916.

In block 916 , cores 102 are woken up by control unit 104 when all cores 102 have written a SYNC 14 . Flow proceeds to decision block 919.

In decision block 919 , the core 102 determines whether it is the primary core 102 of the microprocessor 100 . If so, the process proceeds to block 921 ; otherwise, the process proceeds to block 924 .

In block 921, the primary core 102 issues a stall grant cycle on the microprocessor 100 bus to notify the chipset that it may take power-saving operations across cores (e.g., around the package) with respect to the microprocessor 100 as a whole , such as avoiding snooping of microprocessor 100 cache memory, removing bus clocks (e.g., x86-type BCLK) to microprocessor 100, and asserting other signals on the bus (e.g., x86-type SLP, DPSLP , NAP, VRDSLP), so that the microprocessor 100 removes clock and/or power to various parts of the microprocessor 100 . Although the embodiments described herein relate to a handshake protocol (in block 908) between the microprocessor 100 and a chipset associated with I/O reads, the establishment of STPCLK (in block 909), and stop Allows the release of cycles (in block 921) that have historical relevance to x86 infrastructure systems, it being understood that other embodiments assume relevance to other infrastructure systems with different protocol instruction sets, but may also save power, improve performance and/or reduce complexity. Flow proceeds to block 924.

In block 924 , the core 102 writes a sleep request (eg, a sleep request with the sleep bit 212 set and the S bit 222 clear ) to the sync register 108 . In addition, the sync request indicates in its wakeup event field 204 that the core 102 is only woken up during a wakeup event of the de-assertion of STPCLK (wakeup event of the de-assertion of STPCLK). Therefore, the control unit 104 puts the core 102 into a sleep state. Flow ends at block 924 .

Please refer to FIG. 10 , which is a timing diagram showing an embodiment of the operation of the microprocessor 100 according to the flowchart of FIG. 9 . In this example, the microprocessor 100 is configured with three cores 102, labeled Core 0, Core 1, and Core 2, as shown. However, it should be appreciated that in other embodiments, the microprocessor 100 may include a different number of cores 102 .

Core 0 encounters a MWAIT instruction specifying C-state 4 (MWAIT C4) (each block 902). Core 0 then writes a SYNC C4 and goes to sleep (per block 904). Core 1 encounters a MWAIT instruction specifying C-state 3 (MWAIT C3) (each block 902). Core 1 then writes a SYNC C3 and goes to sleep (per block 904). Core 2 encounters a MWAIT instruction specifying C-state 2 (MWAIT C2) (each block 902). Core 2 then writes a SYNC C2 and goes to sleep (per block 904). As shown, the time to write SYNC Cx may be different in each core. In fact, one or more cores may not encounter a MWAIT instruction until some other event occurs, such as an interrupt.

When all cores have written SYNC Cx, control unit 104 wakes up all cores simultaneously (per block 906). The main core then issues an I/O read bus cycle (per block 908) and waits for the assertion of STPCLK (per block 909). All cores write a SYNC 14 and go to sleep (per block 914). Since only the primary core flushes the shared cache memory 119, issues an I/O read bus cycle and waits for STPCLK assertion, each core may write to SYNC 14 at different times, as shown in the figure. In fact, the primary core may write to SYNC 14 on the order of hundreds of microseconds behind the other cores.

When all cores write to SYNC 14, control unit 104 wakes up all cores simultaneously (per block 916). Only one primary core issues a Stop grant cycle (per block 921). All cores write a sleep request waiting in STPCLK deassertion (~STPCLK) and go to sleep (per block 924). Since only the primary core issues a stall enable cycle, each core may write a sleep request at a different time, as shown.

When the STPCLK signal is de-asserted, the control unit 104 wakes up all cores.

It can be observed from FIG. 10 that core 1 and core 2 can advantageously sleep for an effective period of time while core 0 executes the handshake protocol. It should be noted, however, that the time required to wake up the microprocessor 100 from the package sleep state is generally proportional to the length of the sleep time (eg, how much power is saved while in the sleep state). Therefore, in cases where the package sleep state is relatively long (or even where a single core 102 sleep state time is long), it is desirable to further reduce the occurrence of wakeups and/or the time required for wakeups associated with handshaking protocols. FIG. 11 depicts an embodiment where a single core 102 handles the handshake protocol while the other core 102 remains in sleep state. Furthermore, according to the embodiment of FIG. 11 , power saving is further achieved by reducing the number of cores 102 that are woken up in response to a wakeup event.

Please refer to FIG. 11 , which is an operation flowchart of the microprocessor 100 entering a low power package C-state according to another embodiment of the present invention. The embodiment of FIG. 11 is illustrated using an example in which the microprocessor 100 is coupled to the execution of the MWAIT instruction in the chipset. However, it should be understood that in other embodiments, the operating system employs other power management instructions, and ultimately the synchronized core 102 is integrated into the microprocessor 100 and communicates with a controller describing a different handshaking protocol.

The embodiment of FIG. 11 is similar in some respects to the embodiment of FIG. 9 . However, in an environment where existing operating systems require the microprocessor 100 to enter very low power states and tolerate delays associated therewith, the embodiment of FIG. 11 is designed to facilitate potentially greater power savings. More specifically, the embodiment of FIG. 11 facilitates controlling power to cores and waking up only one of the cores when necessary, such as when processing an interrupt. The embodiment considers that the microprocessor 100 supports two modes of operation in FIG. 9 and FIG. 11 . Furthermore, the mode is configurable, either at manufacture (eg, via fuse 114 ) and/or via software control or automatically determined by microprocessor 100 depending on the particular C-state specified by the MWAIT instruction. Flow begins at block 1102 .

In block 1102 , core 102 encounters a MWAIT instruction (MWAITCx) specifying a target C-state, denoted as Cx in FIG. 11 , and flow proceeds to block 1104 .

In block 1104 , the core 102 writes a sync request into its sync register 108 with a C bit 224 set and a C-status field 226 value of x (labeled SYNC Cx in FIG. 11 ). The sync request also sets the SELECTIVE WAKE-UP (SELWAKE) bit 214 and the PG bit 208 . Furthermore, the sync request indicates in its wakeup event field 204 that the core 102 wakes up on all wakeup events except STPCLK assertion and STPCLK deassertion (˜STPCLK, ie, deassertion of STPCLK). (More preferably, if there are other wake-up events, such as when the AP starts up, the synchronization request specifies that the core 102 will not be woken up). Accordingly, the control unit 104 puts the core 102 into a sleep state, which includes preventing power from being provided to the core 102 due to the PG bit 208 being set. In addition, the core 102 writes back and invalidates the local cache memory and stores (preferably in dedicated random access memory 116 ) its state of the core 102 before writing the synchronization request. When core 102 is subsequently awakened (eg, at blocks 1137, 1132, or 1106), core 102 will restore its state (eg, from PRAM 116). As mentioned above, especially with respect to FIG. 3 , when the last core 102 writes a synchronous request with the selective wake-up bit 214 set, the control unit 104 will automatically prevent all cores 102 except the last write to the core 102. Wake up event (each block 326). Flow proceeds to block 1106 .

In block 1106 , when all cores 102 have written a SYNC Cx, the control unit 104 wakes up the last written core 102 . As described above, the control unit 104 maintains the S bit 222 settings of the other cores 102 even if the control unit 104 wakes up the last core 102 to write to and clears the S bit. Before block 1106, when the core 102 is in sleep state, it may be woken up by a wakeup event, such as an interrupt. However, once the core 102 is woken up in block 1106, the core 102 still executes the microcode due to the MWAIT instruction (block 1102), and remains active during the period in which interrupts are disabled (e.g., the microcode does not allow itself to be interrupted). In microcode, until block 1124. In other words, although no more than all cores 102 have received a MWAIT instruction to enter a sleep state, only individual cores 102 will sleep, but the microprocessor 100 as a package does not indicate to the chipset that it is ready to enter a package sleep state. However, once all cores 102 have agreed to enter a package sleep state, which is indicated by the occurrence of a sync condition at block 1106, the core 102 that was woken up in block 906 (the core 102 that was last written to, which caused the sync condition to occur) is allowed to complete the package sleep state handshake protocol (eg, blocks 1108, 1109 and 1121 shown below) with the chipset without interruption, and without any other core 102 being interrupted. Flow proceeds to block 1108 .

In block 1108, the core 102 writes back and invalidates the shared cache 119, then communicates with the chipset, which may take appropriate action to reduce power consumption. The flow proceeds to block 1109 .

In block 1109, the core 102 waits for the chipset to assert the STPCLK signal. More preferably, if the STPCLK signal is not asserted after a predetermined number of clock cycles, the control unit 104 detects this situation, and wakes up all cores 102 after terminating its ongoing synchronization request, and in the error code field 248 indicates the error. The flow proceeds to block 1121 .

In block 1121, the core 102 issues a stall enable cycle to the chipset on the bus. Flow proceeds to block 1124 .

In block 1124, the core 102 writes a sleep request, e.g., with the sleep bit 212 set and the S bit 222 clear and the PG bit 208 set, into the sync register 108 . Additionally, the sync request specifies in its wakeup event field 204 that the core 102 only wakes up on wakeup events that deassert STPCLK. Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 1132 .

In block 1132 , the control unit 104 detects STPCLK de-assertion and wakes up the core 102 . It should be noted that before the control unit 104 wakes up the core 102 , the control unit 104 also does not limit the power to the core 102 . Beneficially, core 102 is the only core running at this time, which gives core 102 an opportunity to perform whatever action must be performed while no other core 102 is running. Flow proceeds to block 1134 .

In block 1134, the core 102 writes to a register (not shown) of the control unit 104 to unlock each other core 102 specified in the wakeup event field 204 of its corresponding synchronization register 108 wakeup event. Flow proceeds to block 1136 .

In block 1136 , the core 102 processes any wake-up events that are in progress specifying the core 102 . For example, in one embodiment, a system including microprocessor 100 allows both directed interrupts (e.g., interrupts directed to a particular core of microprocessor 100) and non-directed interrupts (eg, interrupts that may be handled by any core 102 of the microprocessor 100 when the microprocessor 100 selects). An example of an undirected interrupt is often referred to as a "low priority interrupt". In one embodiment, the microprocessor 100 preferably directs the non-directed interrupt to the single core 102 that was woken up in the deassertion of STPCLK at block 1132, since it has been woken up, and can handle the interrupt in the expectation that other cores 102 do not have Any wake-up events in progress, so sleep can continue and power is limited. Flow returns to block 1104 .

When the wakeup event is removed (unblcked) in block 1134, except for the core 102 that has been woken up in block 1132, if the core 102 has no specified wakeup event going on, it is beneficial for the core 102 to continue in the sleep state, and Power is limited in each block 1104 . However, when the wakeup event is dismissed in block 1134 , if a specified wakeup event is being processed by the core 102 , the core will be un-power-gated and woken up by the control unit 104 . In this case, a different flow begins at block 1137 in FIG. 11 .

In block 1137 , after the wake event is dismissed in block 1134 , another core 102 (eg, a core 102 other than the core 102 that was dismissed in block 1134 ) is awakened. The other core 102 handles any ongoing wake-up event directed to the other core 102, eg, handles an interrupt. Flow proceeds from block 1137 to block 1104 .

Please refer to FIG. 12 , which is a timing diagram showing an example of the operation of the microprocessor 100 according to the flowchart of FIG. 11 . In this example, microprocessor 100 is configured with three cores 102, labeled Core 0, Core 1, and Core 2, as shown. However, it should be appreciated that in other embodiments, the microprocessor 100 may include a different number of cores 102 .

Core 0 encounters a MWAIT instruction specifying C-state 7 (MWAIT C7) (each block 1102). In this example, C-State 7 allows power to be limited. Core 0 then writes a selective wake-up bit 214 to set (set) ("selective wake-up" as shown in Figure 12) and PG bit 208 to set (set) SYNC C7, and enter sleep state and limit power (each block 1104). Core 1 encounters a MWAIT instruction specifying a C-state of 7 (per block 1102). Core 1 then writes SYNC C7 with selective wakeup bit 214 set and PG bit 208 set, and goes to sleep and limits power (per block 1104). Core 2 encounters a MWAIT instruction specifying a C-state of 7 (per block 1102). Core 2 then writes to SYNC C7 with selective wakeup bit 214 set and PG bit 208 set, and goes to sleep and limits power (per block 1104). (However, in a preferred embodiment depicted at block 314, the last written core cannot limit power). As shown in the figure, the writing time of each core may be different from that of SYNC C7.

When the last written core writes SYNC C7 with selective wake-up bit 214 set (set), the control unit 104 blocks (block off) all wake-up events written to the last core (each block 326), shown in FIG. An example of 12 is core 2. In addition, the control unit 104 only wakes up the last written core (per block 1106 ), since the other cores continue to sleep and limit power, while core 2 performs handshaking with the chipset, thus saving power. Core 2 then issues an I/O read bus cycle (per block 1108) and waits for the assertion of STPCLK (per block 1109). In response to STPCLK, core 2 issues a stop enable cycle (each block 1121), and writes a sleep request with wait for PG bit 208 set (set) in STPCLK release and enters sleep state and limits power (each block 1124 ). The aforementioned cores may sleep and limit power for a relatively long period of time.

When STPCLK fails to assert, control unit 104 only wakes up core 2 (per block 1132). In the example of FIG. 12 , the chipset fails to assert STPCLK which is forwarded to microprocessor 100 in response to the receipt of an undirected interrupt. Microprocessor 100 directs an undirected interrupt to core 2, which saves power as the other cores remain asleep and limits power. The core disarms the wakeup event for other cores (per block 1134) and services undirected interrupts (per block 1136). Core 2 then rewrites a SYNC C7 with selective wakeup bit 214 set and PG bit 208 set, and goes to sleep with power limited (per block 1104).

When core 2 writes SYNC C7 with selective wake-up bit 214 as set (set) and PG bit 208 as set (set), since the sync request of other cores is still in progress, for example, the S bit 222 of other cores is not controlled by Core 2 wakeup is cleared, so the control unit 104 blocks wakeup events for all cores except core 2, eg, last write core (per block 326). Furthermore, control unit 104 only wakes up core 102 (per block 1106). Core 2 then issues an I/O read bus cycle (per block 1108) and waits for the assertion of STPCLK (per block 1109). In response to STPCLK, core 2 issues a stop enable cycle (per block 1121), and writes a sleep request with the PG bit 208 waiting in STPCLK not asserted set (set), and goes to sleep and limits power (per block 1121) A block 1124).

When STPCLK fails to assert, control unit 104 only wakes up core 2 (per block 1132). In the example of Figure 12, STPCLK is deasserted by other unbound interrupts. Therefore, microprocessor 100 directs the interrupt to core 2, which saves power. Core 2 then deasserts the other core's wakeup event (per block 1134) and services the undirected interrupt (per block 1136). Core 2 then writes a SYNC C7 with selective wakeup bit 214 set and PG bit 208 set, and goes to sleep with limited power (per block 1104).

This cycle can last for quite a long time, ie only non-directional interrupts are generated. FIG. 13 is an example showing an indication of a different core interrupt handling except the last write core.

Can be known by comparing Fig. 10 and Fig. 12, the embodiment in Fig. 12 is comparatively favorable, once core 102 starts to enter sleep state (after writing SYNC C7 in the example of Fig. 12), only one core 102 is woken up again with The chipset executes the handshaking protocol, and the other cores 102 remain asleep, which can be a significant advantage if the cores 102 are in a sleep state for a significant amount of time. The power savings can be significant, especially if the operating system recognizes that there is very little processing workload for a single core 102 in the system.

Furthermore, advantageously, only one core 102 is woken up (to service an undirected event, such as a low priority interrupt) as long as no wakeup event is indicated to the other cores 102 . Again, there may be significant advantages if the core 102 is in a sleep state for a relatively long period of time. Except for relatively infrequent undirected interrupts, such as USB interrupts, especially if there is no payload in the system, the power savings can be significant. Further, embodiments may advantageously switch a single core 102 dynamically even if a wakeup event occurs that is indicated to another core 102 (eg, an interrupt operating system indicates to a single core 102, such as an operating system timer interrupt), It implements the encapsulated sleep state protocol and services non-directed wakeup events, as shown in FIG. 13 , in order to enjoy the benefit of waking up only a single core 102 .

Please refer to FIG. 13 , which is a timing diagram showing an example of the operation of the microprocessor 100 according to the flowchart of FIG. 11 . The example of FIG. 13 is similar in many respects to the example of FIG. 12 . However, in the first instance where STPCLK is deasserted, the interrupt is an interrupt directed to core 1 (rather than an undirected interrupt as in the example of FIG. 12). Accordingly, control unit 104 wakes up core 2 (per block 1132 ), and then wakes up core 1 after the wakeup event is dismissed by core 2 (per block 1134 ). Core 2 then writes a SYNC C7 with selective wakeup bit 214 set and PG bit 208 set, and goes to sleep with limited power (per block 1104).

Core 1 services directed interrupts (per block 1137). Core 1 then again writes to SYNC C7 with selective wakeup bit 214 set and PG bit 208 set, and goes to sleep with power limited (per block 1104). In this example, core 2 Write to its SYNCC7 before core 1 writes to its SYNC C7. Thus, while Core 0 still has its S bit 222 set when it wrote the initial SYNC C7, Core 1 still has its S bit 222 cleared when it wakes up. Therefore, when Core 2 writes to SYNC C7 after a de-wakeup event, it is not the last core to write to SYNC C7 request, conversely, Core 1 becomes the last core to write to SYNC C7 request.

When core 1 writes a SYNCC7 with selective wake-up bit 214 set (set) and PG bit 208 set (set), because core 0's synchronization request is still in progress (e.g., it is not recognized by core 1 and core 2 cleared by wake-up), and core 2 (in this example) has written to the SYNC 14 request, so the control unit 104 blocks wake-up events for all cores except core 1, e.g., the last write to core (each block 326 ). Furthermore, control unit 104 only wakes up core 1 (per block 1106). Core 1 then issues an I/O read bus cycle (per block 1108) and waits for STPCLK to assert (per block 1109). In response to STPCLK, core 1 issues a stall enable cycle (per block 1121), writes a sleep request with PG bit 208 set to wait for STPCLK deassertion, and goes to sleep with power limited (per block 1124 ).

When STPCLK is deasserted, control unit 104 only wakes up core 1 (per block 1132). In the example of FIG. 12, STPCLK is deasserted due to an unbound interrupt; therefore, microprocessor 100 directs the unbound interrupt to core 1, which saves power. The cycle in which unbound interrupts are processed by core 1 can last for a considerable amount of time, ie only unbound interrupts are generated. In this way, the microprocessor 100 can advantageously save power by directing non-directed interrupts to the core 102 so that the most recent interrupt is directed, which is shown in the example of FIG. 13 in relation to switching to a different core. Core 1 again deasserts the other cores' wakeup events (per block 1134) and services undirected interrupts (per block 1136). Core 1 then again writes a SYNC C7 with selective wakeup bit 214 set and PG bit 208 set, and goes to sleep with limited power (per block 1104).

It should be appreciated that while embodiments have been described in which the power management instruction is an x86MWAIT instruction, other embodiments in which synchronization requests are used to execute the power management instruction are contemplated. For example, microprocessor 100 may perform similar operations in response to reads by a set of preset I/O port addresses associated with different C-states. As another example, power management instructions may be derived from an ISA different from the x86 architecture.

Dynamic Reconfiguration of Multicore Processors

Each core 102 of the microprocessor 100 generates a configuration-related value based on the configuration of each core 102 of the microprocessor 100 . More preferably, the microcode of each core 102 generates, stores, and uses configuration-dependent values. Embodiment Description The generation of configuration-related values can be dynamic and beneficial, as described below. Examples of configuration related values include, but are not limited to the following.

Each core 102 produces an overall core count related to FIG. 2 above. The overall core count refers to the core count of the overall cores 102 associated with all cores 102 of the microprocessor 100 as compared to the local core count 256 of the cores 102 associated with cores 102 that only reside crystals 406 in the cores 102 . In one embodiment, the core 102 produces an overall core count that is the sum of the product of the core 102 crystal count 258 and the core 102 count per crystal and its local core count 256, as follows:

Overall number of nuclei = (number of crystals x number of nuclei per crystal) + number of local nuclei.

Each core 102 also generates a number of virtual cores. The virtual core count is the overall core count minus the number of deactivated cores 102 having an overall core count lower than the overall core count of the immediate cores 102 . Therefore, in the case that all cores 102 of the microprocessor 100 are available, the overall core number and the virtual core number are the same. However, the virtual core count of a core 102 may differ from its overall core count if one or more cores 102 are disabled or defective. In one embodiment, each core 102 fills its virtual core number into the APIC ID field of its corresponding APIC ID register. However, according to another embodiment (eg, FIGS. 22 and 23 ), this is not the case. Additionally, in one embodiment, the operating system can update the APIC ID in the APIC ID register.

Each core 102 also generates a BSP flag that indicates whether the core 102 is a BSP. In one embodiment, in general (for example, when the function of "all cores BSP" is disabled in FIG. Designate itself as an application processor (Application Processor, AP). After the reset, the AP core 102 initializes, and then enters the sleep state to wait for the BSP notification to start reading and executing instructions. On the contrary, after the AP core 102 is initialized, the BSP core 102 immediately starts to read and execute the instructions of the system firmware, such as the BIOS startup code, which is used to initialize the system (for example, verify whether the system memory and peripheral devices are working normally and initialize and /or configure them) and boot the operating system, eg, load the operating system (eg, from disk), and transfer control to the operating system. Before booting the operating system, the BSP determines the system configuration (eg, the number of cores 102 or logical processors in the system) and stores it in memory so that the operating system can read the system configuration after boot. After the operating system is booted, the AP core 102 is instructed to read and execute operating system instructions. In one embodiment, in general (for example, when the functions of “Modify BSP” and “BSP of all cores” in FIG. 22 and FIG. 23 are disabled respectively), if the number of virtual cores of a core 102 is 0 , designate itself as a BSP, and all other cores 102 designate themselves as an AP core 102 . Preferably, a core 102 fills its BSP flag related configuration value into the BSP flag bit in the APIC base address register corresponding to its APIC. According to one embodiment, as described above, the BSP is the main core 102 in blocks 907 and 919 , which executes the encapsulation sleep state handshake protocol of FIG. 9 .

Each core 102 also generates an APIC base value for filling the APIC base register. The APIC base address is generated based on the APIC ID of the core 102 . In one embodiment, the operating system can update the APIC base address in the APIC base address register.

Each core 102 also produces a crystal master indication indicating whether that core 102 is the master core 102 of the crystal 406 that includes that core 102 .

Each core 102 also generates a chip master indication, which indicates whether the core 102 is the master core including the real-time core 102 chip, assuming that the microprocessor 100 is configured with the chip, which is described in detail above.

Each core 102 calculates a configuration-dependent value and operates using the configuration-dependent value so that the system including the microprocessor 100 operates normally. For example, the system directs an interrupt request to a core 102 based on its associated APIC ID. The APIC ID determines which interrupt request the core 102 should respond to. More specifically, each IRQ includes a DID, and a core 102 responds to an IRQ only if the DID matches the APIC ID of the core 102 (or if the IRID is one to indicate its is a special value that requests all cores 102). As another example, each core 102 must know whether it is a BSP in order for it to execute the initial BIOS code and boot the operating system and, in one embodiment, execute the encapsulated sleep state handshake protocol as described in FIG. 9 . Embodiments are described below (see FIGS. 22 and 23 ) where the BSP flag and APIC ID can be modified from their normal values for specific purposes, such as for testing and/or debugging.

Please refer to FIG. 14 , which is a flowchart showing dynamic reconfiguration of the microprocessor 100 . In the illustration of FIG. 14 , reference is made to the polycrystalline microprocessor 100 of FIG. 4 , which includes two crystals 406 and eight cores 102 . It should be understood, however, that the described dynamic reconfiguration may use microprocessors 100 having different configurations, that is, having more than two crystals or a single crystal, and having more or fewer than eight cores 102 but at least two 102. This operation is described from the perspective of a single core, but each core 102 of the microprocessor 100 dynamically operates and reconfigures the microprocessor 100 as a whole according to the description. Flow begins at block 1402 .

In block 1402, the microprocessor 100 is reset and the hardware of the microprocessor 100 fills the configuration registers of each core 102 with appropriate values based on the number of available cores 102 and the number of crystals residing in the core 104 112 in. In one embodiment, the number of local cores 256 and the number of crystals 258 are hardwired. As described above, hardware may determine whether a core 102 is enabled or disabled by the blown or unblown state of the fuse 114 . Flow proceeds to block 1404 .

In block 1404 , the core 102 reads the configuration word 252 from the configuration register 112 . The core 102 then generates its correlation value based on the configuration word 252 value read in block 1402 . In the case of a multi-crystal microprocessor 100 configuration, the configuration-dependent values generated in block 1404 will not take into account the cores 102 of other crystals 406 . However, the configuration-dependent values generated in blocks 1414 and 1424 (and block 1524 in FIG. 15) will take into account the cores 102 of other crystals 406, as described below. Flow proceeds to block 1406.

In block 1406 , the core 102 causes the value of the enable bit 254 of the local core 102 in the local configuration register 112 to be propagated to the corresponding enable bit 254 of the configuration register 112 of the remote crystal 406 . For example, referring to the configuration of FIG. 4, a core 102 in crystal A 406A associates cores A, B, C, and D (local core) in the configuration register 112 of crystal A 406A (local crystal). The enable bits 254 are propagated to the enable bits 254 associated with cores A, B, C, and D in the configuration register 112 of crystal B 406B (remote crystal). Conversely, a core 102 in crystal B 406B has the enable bits 254 associated with cores E, F, G, and H (local cores) in the configuration register 112 of crystal B 406B (local crystal) propagated to the The enable bits 254 associated with cores E, F, G, and H are in configuration register 112 of crystal A 406A (remote crystal). In one embodiment, the core 102 propagates to other crystals 406 by writing to the local configuration register 112 . More preferably, writing to the local configuration register 112 by the core 102 leaves the local configuration register unchanged, but causes the local control unit 104 to propagate the value of the local enable bit 254 to the remote crystal 406 . Flow proceeds to block 1408 .

In block 1408 , the core 102 writes a sync request into its sync register 108 for a sync case 8 (labeled SYNC 8 in FIG. 8 ). Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 1412 .

In block 1412 , the control unit 104 wakes up the cores 102 when all available cores 102 in the core set specified by the core set field 228 have written a SYNC 8 . It should be noted that, in the case of a multi-crystal 406 microprocessor 100 configuration, the synchronous event occurrence can be a multi-crystal synchronous event occurrence. That is, the control unit 104 will wait to wake up (or interrupt if the core 102 has not set the sleep bit 212 and thus decides not to sleep) the core 102 until the core set field 228 (which may include a core in the crystal 406 102) Write its synchronization request. Flow proceeds to block 1414 .

In block 1414 , the core 102 reads the configuration register 112 again and generates its configuration-related value based on the new value of the configuration word 252 including the correct value of the enable bit 254 transmitted by the remote crystal, and the flow proceeds to decision block 1416 .

In decision block 1416, core 102 decides whether it should disable itself. In one embodiment, fuse 114 is blown because the microcode reads (before decision block 1416) in its reset process to indicate that core 102 should disable itself, so core 102 determines that it needs to disable itself. Fuse 114 may be blown during or after manufacture of microprocessor 100 . In another embodiment, updated fuse 114 values may be scanned into holding registers, as described above, and the scanned values indicate that the core 102 should be disabled. FIG. 15 illustrates another embodiment in which the core 102 determines that it should be deactivated in different ways. If the core 102 determines that it should be disabled, the process proceeds to block 1417 ; otherwise, the process proceeds to block 1418 .

In block 1417 , the core 102 writes the disable core bit 236 to remove itself from the list of available cores 102 , eg, clear its corresponding enable bit 254 in the configuration word 252 of the configuration register 112 . Thereafter, core 102 may prevent itself from executing any further instructions, preferably by setting one or more bits to turn off its clock signal, and remove its power supply. The flow ends in block 1417.

In block 1418 , the core 102 writes a sync request for a sync case 9 (labeled SYNC 9 in FIG. 14 ) into the sync register 108 . Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 1422.

In block 1422 , cores 102 are woken up by control unit 104 when all enabled cores 102 have written a SYNC 9 . Additionally, in the case of a multi-crystal 406 microprocessor 100 configuration, synchronous conditions may occur for a crystal synchronous condition based on updated values in the configuration register 112 . Furthermore, when the control unit 104 determines whether a synchronous condition occurs, the control unit 104 will exclude consideration of disabling its own core 102 in block 1417 . In more detail, in one case, all other cores 102 (except for the core 102 that disabled itself) write A SYNC 9, then the control unit 104 will detect the occurrence of a sync condition (in block 316 ) when the disabled core bit setting of the core 102 that is not disabled itself is written to the sync register 108 in block 1417 . When the control unit 104 determines that a synchronization condition has occurred because the enable bit 254 of the disabled core 102 is clear, the control unit 104 no longer considers the disabled core 102 . That is, since all enabled cores 102, but not disabled cores 102, have written to SYNC 9, regardless of whether disabled cores 102 have written to SYNC 9, the control unit 104 judges that a synchronization condition has occurred. Flow proceeds to block 1424.

In block 1424, if a core 102 is disabled by the operation of another core 102 in block 1417, the core 102 reads the configuration register 112 again, and the new value of the configuration word 252 reflects a disabled core 102. The core 102 then regenerates its configuration-related values based on the new value of the configuration word 252 in a manner similar to that in block 1414 . The presence 102 of a disabled core may cause some configuration dependent values to differ from the new values generated in block 1414 . For example, the number of virtual cores, APIC ID, BSP flag, BSP base address, main crystal main die may change due to the presence of disabled cores 102, as described above. In the next embodiment, after generating configuration-related values, one of the cores 102 (for example, BSP) writes some configuration-related values of all cores 102 of the microprocessor 100 into the non-core dedicated random access memory 116, so that it can It is then read by all cores 102 . For example, in one embodiment, global configuration-related values are read by core 102 to execute an architectural instruction (e.g., x86CPUID instruction) that requests general information about microprocessor 100, such as microprocessor 100 The number of cores 102. Flow proceeds to decision block 1426 .

In block 1426, the core 102 removes reset and begins fetching architectural instructions. Flow ends at block 1426 .

Please refer to FIG. 15 , which is a flowchart showing dynamic reconfiguration of the microprocessor 100 according to another embodiment. In the illustration of FIG. 15 , reference is made to the polycrystalline microprocessor 100 of FIG. 4 , which includes two crystals 406 and eight cores 102 . It should be understood, however, that the described dynamic reconfiguration may use microprocessors 100 having different configurations, that is, having more than two crystals or a single crystal, and having more or fewer than eight cores 102 but at least two 102. This operation is described from the perspective of a single core, but each core 102 of the microprocessor 100 dynamically operates and reconfigures the microprocessor 100 as a whole according to the description. More specifically, FIG. 15 depicts the operation of one core 102 encountering a core disable instruction, whose flow begins at block 1502 , and the operation of the other core 102 , whose operation flow begins at block 1532 .

In block 1502, one of the cores 102 encounters an instruction instructing the core 102 to disable itself. In one embodiment, the instruction is an x86WRMSR instruction. In response, the core 102 sends a reconfiguration message to the other core 102 and sends it an inter-core interrupt signal. More preferably, during the time that interrupts are disabled (e.g., the microcode does not allow itself to be interrupted), the core 102 blocks the microcode from responding to the instruction to disable itself (in block 1502), Or respond to the interrupt (in block 1532 ) and remain in microcode until block 1526 . The flow proceeds from block 1502 to block 1504 .

In block 1532, one of the other cores 102 (e.g., a core other than the core 102 that encountered the disable instruction in block 1502) is interrupted due to the inter-core interrupt communicated in block 1502 and receives a reconfiguration information. As noted above, although the flow at block 1532 is described from the perspective of a single core 102, every other core 102 (e.g., the core 102 not at block 1502) is interrupted at block 1532 and receives the information and The steps in blocks 1504-1526 are performed. Flow proceeds from block 1532 to block 1504 .

In block 1504 , the core 102 writes a sync request for a sync request 10 (labeled SYNC 10 in FIG. 15 ) into its sync register 108 . Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 1506.

In block 1506, when all available cores 102 have written a SYNC 10, the cores 102 are woken up by the control unit 102. It should be noted that, in the case of a multi-crystal 406 microprocessor 100 configuration, the synchronous event occurrence can be a multi-crystal synchronous event occurrence. That is, the control unit 104 will wait to wake up (or interrupt if the core 102 has not decided to go to sleep) the core 102 until specified in the core set field 228 (which may include the core 102 in the crystal 406) and can be enabled (which is indicated by the enable bit) until the core 102 writes its sync request. Flow proceeds to decision block 1508.

In decision block 1508, the core 102 determines whether it is a core 102 that was instructed to disable itself in block 1502. If so, the process proceeds to block 1517; otherwise, the process proceeds to block 1518.

In block 1517 , the core 102 writes the disable core bit 236 to remove itself from the list of available cores 102 , eg, clear its corresponding enable bit 254 in the configuration word 252 of the configuration register 112 . Thereafter, core 102 may prevent itself from executing any further instructions, preferably by setting one or more bits to turn off its clock signal, and remove its power supply. Flow ends in block 1517.

In block 1518 , the core 102 writes a sync request into the sync register 108 for a sync case 11 (labeled SYNC 11 in FIG. 15 ). Therefore, the control unit 104 puts the core 102 into a sleep state. Flow proceeds to block 1522.

In block 1522, when all enabled cores 102 have written a SYNC 11, the cores 102 are woken up by the control unit 104. Additionally, in the case of a multi-crystal 406 microprocessor 100 configuration, synchronization conditions may occur for a multi-crystal synchronization condition based on updated values in the configuration register 112 . Furthermore, when the control unit 104 determines whether a synchronous condition occurs, the control unit 104 will exclude consideration of disabling its own core 102 in block 1517 . In more detail, in one case, all other cores 102 (except for the core 102 that disabled itself) write A SYNC 11, then when determining whether a synchronous situation has occurred because the enabling bit 254 of the disabling core 102 is clear (clear), because the control unit 104 no longer considers disabling the core 102, so when not disabling itself When the core 102 writes to the synchronization register 108 in block 1517, the control unit 104 will detect the occurrence of a synchronization condition (in block 316) (see FIG. 16). That is to say, since all enabled cores 102 have written a SYNC 11, no matter whether the disabled cores 102 have written a SYNC 11 or not, the control unit 104 determines that synchronization has occurred. Flow proceeds to block 1524.

In block 1524 , the core 102 reads the configuration scratchpad 112 whose configuration word 252 will reflect the disabled core 102 disabled in block 1517 . The core 102 then generates its configuration-related value based on the new value of the configuration word 252 . More preferably, the disable command is executed by system firmware (eg, BIOS setup) in block 1502 , and after the core 102 is disabled, the system firmware performs a reboot of the system, eg, after in block 1526 . During the restart period, the microprocessor 100 may operate differently from the previously configured correlation value generation in block 1524 . For example, the BSP during reboot may be a different core 102 than it was before the configuration-related value was generated. As another example, the system configuration information (eg, the number of cores 102 and logical processors in the system) determined by the BSP prior to booting the operating system and stored in memory for the operating system to read may be different. As another example, the APIC ID of the core 102 that is still in use is different from the APIC ID before the configuration-related value was generated, in which case the operating system will indicate an interrupt request and the core 102 will respond to an interrupt that is different from the previous configuration-related value. ask. As another example, the primary core 102 that executes the encapsulation sleep state handshake protocol in FIG. 9 in blocks 907 and 919 may be a core 102 that is different from the core 102 generated by the previous configuration related values. Flow proceeds to decision block 1526.

In block 1526 , the core 102 resumes the tasks it was executing before it was interrupted in block 1526 . Flow ends at block 1526.

Dynamically reconfiguring microprocessor 100 as described herein can be used in a variety of applications. For example, dynamic reconfiguration may be used for testing and/or simulation during the development of microprocessor 100, and/or for field testing. Additionally, a user may wish to know the total amount of performance and/or power consumption of the system using only a subset of cores 102 to run a particular application. In one embodiment, when a core 102 is disabled, it may have its clock stopped and/or power removed such that it consumes substantially no power. Furthermore, in a high-reliability system, each core 102 may periodically check other cores 102 and a specific core 102 selected by a core 102 for failure, and the non-failed core may disable the failed core 102 and make the remaining Core 102 performs dynamic reconfiguration as described above. In this embodiment, the control word 202 may include an additional field that causes the write core 102 to specify that the core 102 is disabled and modifies the operation described in FIG. 15 so that a core can be disabled in block 1517 A core 102 other than core 102 itself.

Please refer to FIG. 16 , which is a timing diagram showing an example of the operation of the microprocessor 100 according to the flowchart of FIG. 15 . In this example, microprocessor 100 is configured with three cores 102, labeled Core 0, Core 1, and Core 2, as shown. However, it should be understood that in other embodiments, the microprocessor 100 may include a different number of cores 102 and may be a single crystal or a multi-crystal microprocessor 100 . In this sequence diagram, the timing of events advances downward.

Core 1 encounters an instruction to disable itself and in response transmits a reconfiguration message and interrupts Core 0 and Core 2 (each block 1502). Core 1 then writes to SYNC 10 and goes to sleep (per block 1504).

Each core 0 and core 2 is eventually interrupted from its current task and reads the information (each block 1532). In response, each of Core 0 and Core 2 writes to SYNC 10 and goes to sleep (each block 1504). As shown in the figure, the time of writing to SYNC 10 may be different for each core. For example, due to the latency of the instruction, the instruction is executed when the interrupt is asserted.

When all cores 102 write to SYNC 10, control unit 104 wakes up all cores simultaneously (per block 1506). Core 0 and Core 2 then decide that they will not disable themselves (per decision block 1508), and write a SYNC 11 and go to sleep (per block 1518). However, since Core 1 decided that it would disable itself, it writes its disable core bit 236 (per block 1517). In this example, core 1 writes its disable core bit 236 after core 0 and core 2 write their respective SYNC 11, as shown. However, since the control unit 104 determines that the S bit 222 is set for each core 102 for which the enable bit 254 is set, the control unit 104 detects that the synchronization condition occurs. That is to say, even if the S bit 222 of core 1 is not set, its enable bit 254 is cleared when the synchronous register 108 of core 1 is written in block 1517 .

When all available cores have written to SYNC 11, control unit 104 wakes up all cores simultaneously (per block 1522). As noted above, in the case of a polycrystalline microprocessor 100, when core 1 writes its disable core bit 236, and local control unit 104 clears core 1's local enable bit 254, respectively, local control unit 104 also propagates Local enable bit 254 to remote crystal 406 . Therefore, the remote control unit 104 also detects the occurrence of a sync state and wakes up all available cores of its crystal 406 at the same time. Core 0 and Core 2 then generate their configuration-related values based on the updated configuration register 112 values (per block 1524 ), and resume their pre-interrupt activity (per block 1526 ).

Hardware semaphore (HARDWARE SEMAPHORE)

Please refer to FIG. 17 , which is a block diagram of the hardware semaphore 118 shown in FIG. 1 . The hardware semaphore 118 includes an owned bit (owned bit) 1702, an owner bit (owner bit) 1704, and a state machine 1706. The state machine 1706 is used to update the owned bit 1702 and the owner bit 1704 in response to being read by the core 102. And the written hardware semaphore 118. More preferably, in order to identify the hardware semaphore 118 currently owned by the core, the number of owner bits 1704 is the log base-2 number of cores 102 in the microprocessor 100 configuration. In another embodiment, the owner bits 1704 include a corresponding bit for each core 102 of the microprocessor 100 . It should be noted that although a set of own bit 1702, owner bit 1704, and state machine 1706 are described as being implemented as a hardware semaphore 118, the microprocessor 100 may include multiple hardware semaphores 118, each of which 118 all comprise a set of above-mentioned hardware. More preferably, microcode running in each core 102 reads and writes the hardware semaphore 118 to take ownership of a resource shared by the core 102 in order to perform operations requiring exclusive reads of the shared resource, which are detailed in described in the example below. The microcode may associate each of the plurality of hardware semaphores 118 with different ownership of shared resources of the microprocessor 100 . More preferably, the hardware semaphore 118 is read and written by the core 102 at a predetermined address in a non-architectural address space of the core 102 . The non-architectural address space can only be accessed by the microcode of a core 102, but cannot be directly accessed by user program code (eg, program instructions of the x86 architecture). The operation of the state machine 1706 to update the own bit 1702 and the owner bit 1704 of the hardware semaphore 118 is described in FIGS. 18 and 19 , and the use of the hardware semaphore 118 is also described later.

Please refer to FIG. 18 , which is a flowchart showing the operation when a core 102 reads the hardware semaphore 118 . Flow begins at block 1802 .

In block 1802 , a core 102 , denoted core x, reads the hardware semaphore 118 . As mentioned above, preferably, the microcode of the core 102 reads the predetermined address in the non-architectural address space where the hardware semaphore 118 resides. Flow proceeds to decision block 1804.

In decision block 1804 , state machine 1706 checks the owner bit 1704 to determine whether core 102 is the owner of hardware semaphore 118 . If so, the flow goes to block 1808; otherwise, the flow goes to block 1806.

In block 1806 , the hardware semaphore 118 returns and reads a zero value in the core 102 to indicate that the core 102 does not own the hardware semaphore 118 , and the flow ends in block 1806 .

In block 1808 , the hardware semaphore 118 returns and reads a value in the core 102 to indicate that the core 102 owns the hardware semaphore 118 , and the process ends in block 1808 .

As mentioned above, the microprocessor 100 may include a number of hardware semaphores 118 . In one embodiment, the microprocessor 100 includes 16 hardware semaphores 118, and when a core 102 reads a predetermined address, it receives a 16-bit data value, each of which corresponds to one of the 16 hardware semaphores 118 A different hardware semaphore 118 , and indicates whether the core 102 reading the predetermined address has the corresponding hardware semaphore 118 .

Please refer to FIG. 19 , which is a flowchart showing the operation when a core 102 writes to the hardware semaphore 118 . Flow begins at block 1902 .

In block 1902, a core 102, denoted core x, writes to the hardware semaphore 118, eg, at a non-architectural default address as described above. Flow proceeds to decision block 1804.

In decision block 1904 , the state machine 1706 checks the owned bit 1702 to determine whether the hardware semaphore 118 is owned by any core 102 or not (free). If owned, the flow proceeds to decision block 1914 ; otherwise, the flow proceeds to decision block 1906 .

In decision block 1906, state machine 1706 checks the written value. If the value is 1, it means that the core 102 wants to take ownership of the hardware semaphore 118 , and the process proceeds to block 1908 . However, if the value is 0, which means that the core 102 intends to relinquish ownership of the hardware semaphore 118 , the flow proceeds to block 1912 .

In block 1908, the state machine 1706 updates the own bit 1702 to 1 and sets the owner bit 1704 to indicate that core x now owns the hardware semaphore 118. Flow ends in block 1908 .

In block 1912 , the state machine 1706 does not perform an update of the own bit 1702 , nor does it perform an update of the owner bit 1704 , and the flow ends in block 1912 .

In decision block 1914 , state machine 1706 checks the owner bit 1704 to determine whether core x is the owner of hardware semaphore 118 . If so, the process proceeds to decision block 1916; otherwise, the process proceeds to block 1912.

In decision block 1916, state machine 1706 checks the written value. If the value is 1, it represents that the core 102 intends to acquire the ownership of the hardware semaphore 118, and the process proceeds to block 1912 (wherein the core 102 already owns the hardware semaphore 118, so no update occurs, as determined in the decision block 1914 judge). However, if the value is 0, it means that the core 102 intends to relinquish the ownership of the hardware semaphore 118 , and the process proceeds to block 1918 .

In block 1918 , the state machine 1706 updates the owning bit 1702 to zero to indicate that no core 102 owns the hardware semaphore 118 now, and the process ends at block 1918 .

As mentioned above, in one embodiment, the microprocessor 100 includes 16 hardware semaphores 118 . When a core 102 writes the predetermined address, it writes a 16-bit data value, each of which corresponds to a different hardware semaphore 118 of one of the 16 hardware semaphores 118, and indicates the core of the write predetermined address 102 whether to request possession (value 1) or to relinquish ownership of the corresponding hardware semaphore 118 (value 0).

In one embodiment, the arbitration logic arbitrates the access request from the core 102 to the hardware semaphore 118 , so that the core 102 serializes the reading/writing of the hardware semaphore 118 by the hardware semaphore 118 . In one embodiment, the arbitration logic uses a round-robin fairness algorithm (Round-Robin Fairness Algorithm) between the cores 102 to access the hardware semaphore 118 .

Please refer to FIG. 20 , which is a flowchart showing the operation when the microprocessor 100 uses the hardware semaphore 118 to execute a resource requiring exclusive ownership. More specifically, the hardware semaphore 118 is used to ensure that only one core 102 executes a writeback at a time if two or more cores 102 have each encountered a writeback and invalidated the shared cache 119 instruction , and invalidate the shared cache memory 119. The operation is described in terms of a single core, but each core 102 of the microprocessor 100 as a whole ensures that one core 102 performs the writeback and disables the other core 102 in accordance with the present invention. That is, the operation of FIG. 20 ensures that the WBINVD instruction process is serialized (Serialized). In one embodiment, the operations of FIG. 20 may be implemented in a microprocessor 100 that executes a WBINVD instruction according to the embodiment of FIGS. 7A-7B . Flow begins at block 2002.

In block 2002, a core 102 encounters a cache control instruction, such as a WBINVD instruction. The flow proceeds to block 2004.

In block 2004 , the core 102 writes a 1 to the WBINVD hardware semaphore 118 . In one embodiment, the microcode has allocated one of the hardware semaphores 118 to the WBINVD operation. The core 102 then reads the WBINVD hardware semaphore 118 to determine if it has taken ownership. The process proceeds to decision block 2006 .

In decision block 2006, if the core 102 determines that it has acquired the ownership of the WBINVD hardware semaphore 118, the flow proceeds to block 2008; otherwise, the flow returns to block 2004 to try to acquire ownership again. It should be noted that when the microcode of the real-time kernel 102 loops through blocks 2004 to 2006, it will eventually be interrupted by the core 102 that owns the WBINVD hardware semaphore 118 because the core 102 is executing in block 702 in FIGS. 7A-7B The WBINVD instruction sends an interrupt to the real-time core 102 . More preferably, through each loop, the microcode of the real-time core 102 checks the interrupt status register to see if one of the other cores 102 (for example, the core 102 that owns the WBINVD hardware semaphore 118) sends an interrupt to Instant Core 102. The just-in-time core 102 will then execute the operations of FIGS. 7A-7B , and resume operations according to FIG. 20 in block 749 to attempt to acquire ownership of the hardware semaphore 118 to execute its WBINVD instruction.

In block 2008, the core 102 has taken ownership and flow proceeds to block 702 in FIGS. 7A-7B to execute the WBINVD instruction. As part of the WBINVD instruction operation, the core 102 relinquishes ownership of the WBINVD hardware semaphore 118 by writing a zero to the WBINVD hardware semaphore 118 at block 748 in FIGS. 7A-7B . The process ends at block 2008.

An operation similar to that described in FIG. 20 may be performed by the microcode to obtain exclusive ownership of other shared resources. Another resource that a core 102 can obtain exclusive ownership of used by using a hardware semaphore 118 is non-core 103 registers, which are shared by cores 102 . In one embodiment, the non-core 103 registers include a control register including fields for each core 102 . This field controls the operational aspects of each core 102 . Since the fields are in the same register, when a core 102 wants to update its respective field but cannot update the fields of other cores 102, the core 102 must read the control register, modify the read value, then writes back the modified value to the control register. For example, the microprocessor 100 may include an uncore 103 performance control register (Performance Control Register, PCR), which is used to control the bus clock ratio of the core 102 . In order to update its bus clock ratio, a particular core 102 must read, modify and write back the PCR. Thus, in one embodiment, the microcode is configured to perform an efficient atomic read/modify/writeback of a PCR when the core 102 owns the hardware semaphore 118 associated with the PCR. The bus clock ratio determines the clock frequency of the single core 102 as a multiple of the clock frequency of the supporting microprocessor 100 via an external bus.

Another resource is a Trusted Platform Module (TPM). In one embodiment, the microprocessor 100 executes a TPM running microcode in the core 102 . At a given instant in time, microcode running on a core 102 or one of the cores 102 implements the TPM. However, the cores 102 implementing the TPM may change over time. By using the hardware semaphore 118 associated with the TPM, the microcode of the cores 102 can ensure that only one core 102 implements the TPM at a time. More specifically, the core 102 currently executing the TPM writes the TPM state to the dedicated random access memory 116 before relinquishing implementation of the TPM, and the core 102 that takes over implementing the TPM reads the TPM state from the dedicated random access memory 116. state. The microcode of each core 102 is configured such that when the core 102 intends to become the core 102 executing the TPM, the core 102 first takes ownership of the TPM hardware semaphore 118 before reading the TPM state from the dedicated random access memory 116, And start executing TPM. In one embodiment, the TPM substantially conforms to the TPM specification issued by the Trusted Computing Group, such as the ISO/IEC11889 specification.

As mentioned above, the conventional solution to resource contention between multiple processors is to use software semaphores in system memory. Potential advantages of the hardware semaphore 118 described herein are that it avoids the need for extra traffic on an extra memory bus, and it can be accessed faster than accessing system memory.

Interrupt, non-sleep synchronous request

Please refer to FIG. 21 , which is a timing diagram showing an example of the operation of the core 102 issuing a non-sleep synchronization request according to the flowchart in FIG. 3 . In this example, microprocessor 100 is configured with three cores 102, labeled Core 0, Core 1, and Core 2, as shown. However, it should be understood that in other embodiments, the microprocessor 100 may include a different number of cores 102 .

Core 0 writes a SYNC 14 that is not set in the sleep bit 212, nor is it set in the optional wakeup bit 214 (eg, a non-sleep sync request). Therefore, the control unit 104 allows core 0 to keep running (branch "No" of each decision block 312).

Core 1 eventually also writes a non-sleep SYNC 14 and the control unit 104 allows Core 1 to keep running. Finally, Core 2 writes a non-sleep SYNC 14 . As shown, the time each core writes to SYNC 14 may be different.

When all cores have written non-sleep sync 14, the control unit 104 simultaneously sends a sync interrupt to each of core 0, core 1 and core 2. Each core then receives and services the isochronous interrupt (unless the isochronous interrupt is masked, in which case the microcode typically polls the isochronous interrupt).

Boot Processor Assignment

In one embodiment, as described above, normally (e.g., when the functionality of "All Cores BSP" in FIG. working system. In one embodiment, the number of virtual cores is preset to 0 by the core 102BSP normally (eg, when the "Modify BSP" and "All Cores BSP" functions of FIGS. 22 and 23, respectively, are disabled).

However, the inventors have observed that it may be advantageous to specify the BSP in a different manner, an example of which will be described below. For example, many tests of a portion of the microprocessor 100, especially during manufacturing testing, are performed by booting the operating system and running program code to ensure that the portion of the microprocessor 100 is functioning properly. Since the BSP core 102 performs system initialization and starts the operating system, the BSP core 102 can operate in ways that the AP core cannot. In addition, it can be seen from observation that even in a multi-threaded operating environment, the BSP usually bears a larger part of the processing load than the AP. Therefore, the AP core 102 cannot be tested as comprehensively as the BSP core 102 . Finally, there may be certain actions that only need to be performed by the BSP core 102 on behalf of the microprocessor 100 as a whole, such as the encapsulated sleep state handshake protocol as depicted in FIG. 9 .

Thus, the embodiments describe that any core 102 can be designated as a BSP. In one embodiment, during testing of the microprocessor 100, the test is run N times, where N is the number of cores 102 of the microprocessor 100, and in each run of the test the microprocessor 100 is reconfigured so that The BSPs are different cores 102 . This may advantageously provide better test coverage during manufacturing and also advantageously expose bugs in microprocessor 100 during microprocessor 100 design. Another advantage is that each core 102 can have a different APIC ID in different runs and thus respond to different interrupt requests, which can provide wider test coverage.

Please refer to FIG. 22 , which is a flowchart showing a procedure for configuring the microprocessor 100 . The description in FIG. 22 refers to the polycrystalline microprocessor 100 in FIG. 4 , which includes two crystals 406 and eight cores 102 . However, it should be understood that the dynamic reconfiguration described herein may use a microprocessor 100 having a different configuration, that is, having more than two crystals or a single crystal, and having more or less than eight cores 102 but at least two 102 cores. This operation is described from the perspective of a single core, but each core 102 of the microprocessor 100 dynamically operates and reconfigures the microprocessor 100 as a whole according to the description. Flow begins at block 2202.

In block 2202, the microprocessor 100 is reset and performs an initial portion of its initialization, preferably in a manner similar to that described above for FIG. 14 . However, generation of configuration-related values, such as block 1424 in FIG. 14 , particularly the APIC ID and BSP flag, is performed in the manner described in blocks 2203-2204. The process goes to block 2203.

In block 2203, the core 102 generates its virtual core count, better described in FIG. 14 . Flow proceeds to decision block 2204.

In decision block 2204, the core 102 samples an indication to determine whether a function is enabled. This functionality is referred to herein as the "Modify BSP" functionality. In one embodiment, blowing a fuse 114 may modify the functionality of the BSP. More preferably, in the test process, instead of blowing the fuse 114 that modifies the BSP function, a true value (True) is scanned into the save temporary register bit associated with the modifying BSP function fuse 114, as described above shown in Figure 1 to enable the modified BSP functionality. In this way, the modified BSP function is not permanently enabled in some microprocessors 100, but disabled after power-up. More preferably, the operations in blocks 2203 to 2214 are performed by the microcode of the core 102 . If the modified BSP function is enabled, the process proceeds to block 2205 . Otherwise, the process proceeds to block 2206.

In block 2205, the core 102 modifies the number of virtual cores generated in block 2203. In one embodiment, the core 102 modifies the number of virtual cores to generate a result of a Rotate function (Rotate function) of the number of virtual cores generated in block 2203 and a rotation amount, as follows:

Number of virtual cores = cycle(cycle amount, number of virtual cores).

The round robin function, in one embodiment, cycles the number of virtual cores between cores 102 by a round number. The cycle amount is a value that blows the fuse 114, or better said, is scanned into the holding register during the test. Table 1 shows the number of virtual cores for each core 102 in sequential pairs (crystal count 258, local core count 256) are shown in the left row of an exemplary configuration, and the amount per cycle is shown in the top row, where The number of crystals 406 is two and the number of cores 102 per crystal 406 is four, and all cores 102 can be enabled. In this way, the tester is authorized to have the core 102 generate its virtual core number, and APIC ID, eg, any valid value. Although the method for modifying the number of virtual cores is described in one embodiment, other embodiments are also contemplated. For example, the direction of circulation can be reversed as indicated in Table 1. Flow proceeds to block 2206.

Table 1

0 1 2 3 4 5 6 7 (0,0) 0 7 6 5 4 3 2 1 (0,1) 1 0 7 6 5 4 3 2

(0,2) 2 1 0 7 6 5 4 3 (0,3) 3 2 1 0 7 6 5 4 (1,0) 4 3 2 1 0 7 6 5 (1,1) 5 4 3 2 1 0 7 6 (1,2) 6 5 4 3 2 1 0 7 (1,3) 7 6 5 4 3 2 1 0

In block 2206 , the core 102 fills the local APIC ID register with the preset number of virtual cores generated in block 2203 or the modified value generated in block 2203 . In one embodiment, the APICID register can be read by the core 102 from itself at memory address 0x0FEE00020 (eg, via the BIOS and/or operating system). However, in another embodiment, the APIC ID register can be read by the core 102 at MSR address 0x802. Flow proceeds to decision block 2208.

In decision block 2208, the core 102 determines whether the APIC ID it populated in block 2208 is zero. If so, the process proceeds to block 2212; otherwise, the process proceeds to block 2214.

In block 2212, the core 102 sets its BSP flag to true to indicate that the core 102 is a BSP. In one embodiment, the BSP flag is a bit of the x86 APIC base address register (IA32_APIC_BASE MSR) of the core 102 . Flow proceeds to decision block 2216.

In block 2214, the core 102 sets the BSP flag to false to indicate that the core 102 is not a BSP, eg, in an AP. Flow proceeds to decision block 2216.

In decision block 2216 , the core 102 determines whether it is a BSP, eg, designates itself as the BSP core 102 in block 2212 rather than designating itself as the AP core 102 in block 2214 . If so, the process proceeds to block 2218; otherwise, the process proceeds to block 2222.

In block 2218, the core 102 begins fetching and executing system initialization firmware (eg, BSP BIOS bootloader code). This may include instructions related to the BSP flag and APIC ID, for example, an instruction to read the APICID register or the APIC base address register, in which case the core 102 restores what was written at blocks 2206 and 2212/2214. value. It may also include being the sole core 102 of the microprocessor 100 to perform operations on behalf of the microprocessor 100 as a whole, such as the encapsulated sleep state handshake protocol described in FIG. 9 . More preferably, the BSP core 102 starts fetching and executing the system initialization firmware in a defined architectural reset vector. For example, on the x86 architecture, the reset vector points to 0xFFFFFFF0. More preferably, executing the system initialization firmware includes booting the operating system, eg, loading the operating system and transitioning to the controlling operating system. Flow proceeds to block 2224.

In block 2222, the core 102 halts itself and waits for a boot sequence from the BSP to begin fetching and executing instructions. In one embodiment, the boot sequence received from the BSP includes an interrupt vector to the AP system initialization firmware (eg, AP BIOS code). This may include instructions related to the BSP flag and APIC ID, in which case core 102 restores the values written in blocks 2206 and 2212/2214. Flow proceeds to block 2224.

In block 2224, when the core 102 executes the instruction, the core 102 receives an interrupt request based on the APIC ID written in its APIC ID register in block 2206 and responds to the interrupt request. Flow ends at block 2224.

As mentioned above, according to an embodiment, the core 102 whose number of virtual cores is zero is preset as a BSP. However, the inventors have observed that there may be situations where it is advantageous for all cores 102 to be designated as BSPs, examples of which are described below. For example, microprocessor 100 developers have invested a significant amount of time and cost in developing a large test body designed to run in a single-core on a single-threaded, and the developers want to use a single-threaded Core test to test the multi-core microprocessor 100 . For example, the test might be run on the old and well-known DOS operating system in x86 real mode.

Running these tests on each core 102 can be done in a sequential fashion using the modified BSP function described in FIG. All cores 102 but one core 102 are used for testing. However, the inventors have appreciated that this will require more time (e.g., about 4 times in the case of a 4-core microprocessor 100) than running the tests simultaneously in all cores 102, and furthermore, each individual test required to test Microprocessor 100 part time is precious, especially when manufacturing hundreds of thousands or more of microprocessor 100 parts, especially when many tests are tested in very expensive test equipment.

In addition, other possibilities are that a speed in the logic of the microprocessor 100 may be affected by the fact that more than one core 102 (or all of the cores 102) are running at the same time because it generates more heat and/or draws more power. The case where the path will be subjected to more stress. Tests run in this continuous fashion may not create additional stress and reveal this velocity path.

Therefore, the embodiment describes that all cores 102 can be dynamically assigned to the BSP core 102 so that all cores 102 can execute a test at the same time.

Please refer to FIG. 23 , which is a flowchart showing a program for configuring the microprocessor 100 according to another embodiment. The description in FIG. 23 refers to the polycrystalline microprocessor 100 in FIG. 4 , which includes two crystals 406 and eight cores 102 . However, it should be understood that the dynamic reconfiguration described herein may use a microprocessor 100 having a different configuration, that is, having more than two crystals or a single crystal, and having more or less than eight cores 102 but at least two 102 cores. This operation is described from the perspective of a single core, but each core 102 of the microprocessor 100 dynamically operates and reconfigures the microprocessor 100 as a whole according to the description. Flow begins at block 2302.

In block 2302, the microprocessor 100 is reset and performs an initial portion of its initialization, preferably in a manner similar to that described above for FIG. 14 . However, generation of configuration-related values, such as block 1424 in FIG. 14 , particularly the APIC ID and BSP flag, is performed in the manner described in blocks 2304-2312. Flow proceeds to decision block 2304.

In decision block 2304, the core 102 detects that a function can be enabled. This functionality is referred to herein as the "all cores BSP" functionality. More preferably, blowing fuse 114 enables all core BSP functions to be enabled. More preferably, in the test process, instead of blowing the fuses 114 of all core BSP functions, a true value (True) is scanned into the save temporary register bits relevant to all core BSP function fuses 114, As shown in Figure 1 above, to enable all of the core BSP functions. In this approach, the all core BSP functions are not permanently enabled in part of the microprocessor 100, but are disabled upon power-up. More preferably, the operations in blocks 2304 to 2312 are performed by microcode of the core 102 . If the all-core BSP function is enabled, the process proceeds to block 2305 . Otherwise, the process proceeds to block 2203 in FIG. 22 .

In block 2305, the core 102 sets its virtual core count to zero regardless of the local core count 256 and the core 102 crystal 258 count. Flow proceeds to block 2306.

In block 2306, the core 102 fills the local APICID register with the number of virtual cores set to zero in block 2305. Flow proceeds to block 2312.

In block 2312, regardless of the number of local cores 256 and the number of crystals 258 of the core 102, the core 102 sets its BSP flag to True to indicate that the core 102 is a BSP. Flow proceeds to block 2315.

In block 2315, whenever a core 102 executes a memory access request, the microprocessor 100 modifies the higher address bits of each core 102 memory access request address respectively, so that each core 102 accesses its separate memory space. That is, depending on the core 102 that generated the memory access request, the microprocessor 100 modifies the upper address bits so that the upper address bits have a unique value for each core 102 . In one embodiment, microprocessor 100 modifies the higher address bits indicated by the value of blown fuse 114 . In another embodiment, the microprocessor 100 modifies the upper address bits based on the local core number 256 and the crystal number 258 of the core 102 . For example, in an embodiment where the number of cores in a microprocessor 100 is four, the microprocessor 100 modifies the upper two bits of the memory address and generates a unique value. In practice, the memory space addressable by the microprocessor 100 is divided into N subspaces, where N is the number of cores 102 . The test program was developed such that it constrains itself to specify the address of the lowest subspace among the N subspaces. For example, assume that the microprocessor 100 is capable of addressing 64 GB of memory and that the microprocessor 100 includes four cores 102 . The test was developed to access only the lowest 8GB of memory. When core 0 executes an instruction that accesses memory address A (lower 8 GB in memory), microprocessor 100 generates an address in memory bus A (unmodified); when core 1 executes an instruction that accesses the same memory address A During the instruction, the microprocessor 100 generates an address in the memory bus A+8GB; when the core 2 executes an instruction to access the same memory address A, the microprocessor 100 generates an address in the memory bus A+16GB; and When core 3 executes an instruction that accesses the same memory address A, the microprocessor 100 generates an address in memory bus A+32GB. In this manner, advantageously, the core 102 will not conflict in its accesses to memory, which allows the test to execute correctly. More preferably, single-thread testing is performed in a stand-alone testing machine capable of testing the microprocessor 100 alone. The microprocessor 100 developer develops test data and is provided to the microprocessor 100 by the test machine, conversely, the microprocessor 100 developer develops result data, which is provided by the test machine during a memory write access Compare the results of the data written by the microprocessor 100 to ensure that the microprocessor 100 writes correct data. In one embodiment, a shared cache 119 (e.g., a top-level cache that generates addresses used in external bus transactions) is part of the microprocessor 100 and is configured to when all core BSP functions are enabled Modify higher address bits. Flow proceeds to block 2318.

In block 2318, the core 102 begins fetching and executing system initialization firmware (eg, BSP BIOS bootloader code). This may include instructions related to the BSP flag and APIC ID, for example, an instruction to read the APIC ID register or the APIC base address register, in which case the core 102 restores what was written in block 2306 Enter a value of zero. More preferably, the BSP core 102 starts to read and execute the system initialization firmware in an architecturally-defined reset vector. For example, on the x86 architecture, the reset vector points to address 0xFFFFFFF0. More preferably, executing the system initialization firmware includes booting an operating system, eg, loading the operating system and changing to control the operating system. Flow proceeds to block 2324.

In block 2324, when the core 102 executes the instruction, the core 102 receives an interrupt request based on the APIC ID value written in its APIC ID register to a value of zero in block 2306 and responds to the interrupt request. Flow ends at block 2324.

While an embodiment in which all cores 102 are designated as the BSP has been described in FIG. 23 , other embodiments contemplate that more, but less than all cores 102 are designated as the BSP.

Although the embodiment is described in the context of an x86-type system in which each core 102 uses a local APIC and has an association between the local APIC ID and the BSP designation, it should be understood that the boot processor's The designation is not limited to x86 implementations, but may be used in systems with different system architectures.

Propagation of microcode patches (PATCH) for multicore

As previously observed, there are many important functions likely to be performed primarily by the microcode of a microprocessor, and in particular, it requires correct communication and coordination among instances of the microcode executing in the microprocessor's multi-core. Due to the complexity of microcode, there is a significant chance that a bug will be present in the microcode that needs to be corrected. This can be accomplished via microcode patching that replaces the old microcode instruction that caused the error with a new microcode instruction. That is, the microprocessor includes specific hardware that benefits from microcode patching. In general, it is desirable to apply the micromodification to all cores of the microprocessor. Traditionally, patching has been performed by individually executing an architectural instruction in each core. However, traditional methods can be problematic.

First, the fix is related to inter-core communication using microcode instances (e.g., core synchronization, hardware semaphore usage) or functionality that requires microcode inter-core communication (e.g., cross-core alignment requests, cache control operations, or power management , or dynamic multi-core microprocessor configuration) related. Architecting the execution of the patch application separately on each core may result in a time window in which the microcode patch is applied to some cores but not to others (or a previous patch is applied to some cores and the new patch is applied to other cores). This may cause a communication failure between the cores and incorrect operation of the microprocessor. If all cores of the microprocessor are patched with the same microcode, other expected and unexpected problems may also arise.

Second, the microprocessor's architecture specifies many functions that, in some instances, may be supported by the microprocessor and not supported by other microprocessors. During operation, the microprocessor is able to communicate with system software that supports that particular function. For example, in the case of an x86 architecture microprocessor, the x86CPUID instruction can be executed by system software to determine the supported feature set. However, instructions (for example, CPUID) that determine function settings are executed in each core of the microprocessor, respectively. In some cases, a function may be disabled due to an error present at the time and disable the microprocessor. However, a subsequent microcode patch that fixes this bug can be developed so that this feature can be enabled after the patch is applied. However, if the patch is implemented in a conventional manner (e.g., by applying individual instructions in each core to apply the patch instruction, separately to each core), different cores may differ depending on whether the patch has been applied to the core, in A given point in time indicates different functional configurations. This can be problematic, especially when the system software (such as an operating system, for example, to facilitate thread migration between cores) expects all cores of the microprocessor to have the same feature set. In particular, some system software has been observed to only get the functional configuration of one core and assume the other cores have the same functional configuration.

Furthermore, each core controls and/or microcode instances that communicate with non-core resources shared by the cores (eg, synchronization-related hardware, hardware semaphores, shared PRAM, shared caches, or service processing units). Therefore, since one of the cores has a microcode patch and the other core does not (or two cores have different microcode patches), generally speaking, the microcode of two different cores uses two different microcode patches at the same time. methods of controlling or communicating with non-nuclear resources can be problematic.

Finally, the microcode patching hardware on the microprocessor can also be patched in a conventional way, but it may cause interference with other core patching applications and patching operations by a core, for example, if parts of the patching hardware are shared between cores.

More preferably, microcode patches are applied to embodiments of a multi-core microprocessor in an atomic fashion at the architectural instruction level to address the problems described herein. First, patches are applied to the overall microprocessor 100 in response to the execution of an architectural instruction in a single core 102 . That is, embodiments need not require system software to execute an application microcode patching instruction (described below) in each core 102 . More specifically, a single core 102 that encounters the apply microcode patch instruction will send a message and interrupt the other cores 102 to cause its microcode to patch that portion of the instance, and all microcode instances cooperate with the other microcode to make the Microcode patches are applied to the microcode patch software of each core 102 and share the patched hardware of the microprocessor 100 when interrupts are disabled in all cores 102 . Second, the microcode instance running in all cores 102 and implementing the atomic patch apply mechanism cooperates with another microcode so that it avoids executing any architectural instructions (except for an apply microcode patch instruction) in the microcode After all cores 102 of processor 100 have agreed to apply the patch, until all cores 102 are done. That is, when any core 102 uses the microcode patch, no core 102 executes an architectural instruction. Also, in a more preferred embodiment, all cores 102 go to the same place in the microcode to execute the patch application with interrupts disabled, and then the cores 102 only execute the microcode instructions for patching until the microcode All cores of the processor 100 confirm that the patch has been used. That is, when any core 102 of the microprocessor 100 is using the patch, no core 102 executes the microcode instruction except the microcode instruction patched by the microcode.

Please refer to FIG. 24 , which is a block diagram showing a multi-core microprocessor 100 according to another embodiment. The microprocessor 100 is similar in many respects to the microprocessor 100 of FIG. 1 . However, the microprocessor 100 of FIG. 24 also includes a service processing unit (Service Processing Unit, SPU) 2423 in its non-core 103, a service processing unit (SPU) initial address register 2497, a non-core microcode ROM (Read Only Memory, ROM) 2425 and a random access memory (Random Access Memory, RAM) 2408 patched by a non-core microcode. In addition, each core 102 includes a core PRAM 2499 , a patched Content Addressable Memory (CAM) 2439 and a core microcode ROM 2404 .

Microcode includes microcode instructions. The microcode instructions are non-architectural instructions stored in one or more memories of the microprocessor 100 (e.g., non-core microcode ROM 2425, non-core microcode patch RAM 2408, and/or core microcode ROM 2404), wherein the microcode instructions Extracted by a core 102 based on a fetch address stored in the non-architectural Micro-program Counter (Micro-program Counter, Micro-PC), and used by the core 102 to implement the instruction set architecture of the microprocessor 100 instruction. More preferably, the microcode instruction is translated by a microtranslator (Microtranslator), and its microcode is executed by the execution unit of the core 102, or in another embodiment, the microcode instruction is directly executed by Executed by an execution unit, in this case microcode instructions are microinstructions. The microcode instruction is a non-architectural instruction meaning that it is not indicative of the instruction set architecture (ISA) of the microprocessor 100 , but is encoded according to an instruction set different from the instruction set of the architecture. The non-architectural micro program counter is not defined by the instruction set architecture of the microprocessor 100 and is different from the architecturally-defined program counter of the core 102 . The microcode is used to implement some or all of the instructions of the microprocessor's ISA instruction set as follows. In response to decoding a microcode to execute an ISA instruction, the core 102 transitions to control a microcode routine (Routine) associated with the ISA. The microcode routines include microcode instructions. The execution unit executes the microcode instruction, or according to a preferred embodiment, the microcode instruction is further translated into a microinstruction executed by the execution unit. The execution result of the microcode instruction (or the microcode translated by the microcode instruction) executed by the execution unit is the result defined by the ISA instruction. Thus, co-execution of the microcode (or microinstructions translated from the microcode routine instructions) routine associated with the ISA instruction is "implementing" the ISA instruction by the execution unit. That is, the operations specified by the ISA instruction in the inputs specified by the ISA instruction are performed by collective execution performed by the execution units executing the microcode instruction (or microinstructions translated from the microcode instruction), to Produces a result as defined by the ISA directive. Additionally, the microcode instructions may be executed (or translated into microinstructions that are executed) when the microprocessor is reset in order to configure the microprocessor.

The core microcode ROM 2404 holds the microcode executed by the particular core 102 that includes the core microcode ROM 2404 . The non-core microcode ROM 2425 also holds the microcode executed by the core 102 . However, in contrast to the core microcode ROM 2404, the uncore ROM 2425 is shared by the core 102. More preferably, since the uncore ROM 2425 has a greater access time than the core ROM 2404, the uncore ROM 2425 has microcode routines that require less performance and/or execute less frequently. In addition, the non-core ROM 2425 holds program codes extracted and executed by the SPU 2423 .

The non-core microcode patch RAM 2408 is also shared by the core 102 . The non-core microcode patch RAM 2408 holds microcode instructions executed by the core 102 . When the extraction address matches the contents of one of the entries in the repair CAM 2439, then the repair CAM 2439 has a microcode extraction address output by the repair CAM 2439 to a microsequencer (Microsequencer) ) patch address. In this case, the patch address output by the microsequencer is the microcode fetch address, rather than the next sequential fetch pointer address (or target address in the case of a branch instruction), as the non-core patch RAM 2408 A reply to the patch microcode instruction is output. For example, a patched microcode instruction is fetched from uncore patched RAM 2408 rather than from either the uncored ROM 2425 or the cored ROM 2404 because the patched microcode instruction and/or the microcoded instructions following it are a source of errors A microcode instruction is fetched. Thus, the patched microcode instructions effectively replace, or patch, unintended microcode instructions residing in the core ROM 2404 or the non-core microcode ROM 2425 at the original microcode fetch address. More preferably, the patch CAM 2439 and patch RAM 2408 are loaded in response to architectural instructions contained in system software, such as the BIOS or operating system running on the microprocessor 100 .

Among other things, the uncore PRAM 116 is used by the microcode to store values used by the microcode. Some valid functions of these values are constants

Except possibly via a patch or in response to the execution of an instruction that explicitly modifies the value (e.g., a WRMSR instruction), when the microprocessor 100 is reset and not modified during operation of the microprocessor 100 , because it is an immediate value stored in the core microcode ROM 2404 or the non-core microcode ROM 2425 or when the microprocessor 100 is manufactured or written to the non-core PRAM 116 by the microcode point to blow the fuse 114. Advantageously, these values can be modified via the patching mechanism described herein without requiring changes to the core microcode ROM 2404 or the non-core microcode ROM 2425, which can be very expensive, and without requiring one or more unblown fuses device 114.

In addition, the uncore PRAM 116 is used to store patch code fetched and executed by the SPU 2423, as described herein.

The core PRAM 2499, like the uncore PRAM 116, is private, or non-architectural, which means that the core PRAM 2499 is not located in the microprocessor 100 architectural user program address space. However, unlike the uncore PRAM 116 , each PRAM 2499 is only read by its respective core 102 and is not shared by other cores 102 . Like the uncore PRAM 116, the core PRAM 2499 is also used by the microcode to store values used by the microcode. Advantageously, these values can be modified via the patching mechanisms described herein without requiring changes to either the core microcode ROM 2404 or the non-core microcode ROM 2425.

The SPU 2423 includes a stored program processor, which is an adjunct distinct from each core 102 . Although the core 102 is structurally capable of executing instructions of the ISA of the core 102 (eg, x86 ISA instructions), the SPU 2423 is structurally incapable of doing so. Therefore, for example, the operating system cannot run in the SPU 2423 , nor can the ISA operating system scheduler of the core 102 (eg, ISA instructions for x86) run in the SPU 2423 . In other words, the SPU 2423 is not a system resource managed by the operating system. More specifically, the SPU 2423 performs operations for tuning the microprocessor 100 . Additionally, the SPU 2423 can help measure the performance and other functions of the core 102 . More preferably, the SPU 2423 is smaller, less complex, and consumes less power than the core 102 (e.g., in one embodiment, the SPU 2423 includes built-in Clock Gating ). In one embodiment, the SPU2423 includes a FORTH CPU core.

Asynchronous events that may occur with debug instructions executed by the core 102 may not be handled well. Advantageously, however, the SPU 2423 can be commanded by a core 102 to detect the event and perform operations such as creating a log or modifying the behavior of various aspects of the core 102 and/or the microprocessor 100 external bus interface as a response to detecting this event. The SPU 2423 can provide the log file information to the user, and it can also interact with the tracker to request the tracker to provide the log file information or request the tire tracker to perform other actions. In one embodiment, the SPU 2423 has access to control registers of the memory subsystem and programmable interrupt controllers of each core 102 , and control registers of the shared cache 119 .

Examples of events that the SPU 2423 can detect include the following: (1) a core 102 is running, for example, the core 102 has not retired any programmable instructions within a number of clock cycles; (2) a core 102 Loading data from a non-cache area in memory; (3) temperature changes in the microprocessor 100; (4) the operating system requests a change in bus clock ratio in the microprocessor 100 and/or Or request a change in the microprocessor 100 voltage level; (5) the microprocessor 100 changes the voltage level and/or the bus clock ratio according to itself, for example, to achieve power saving and improve performance; (6) a An internal timer of the core 102 expires; (7) a high-speed buffer snoop (snoop), which bumps into a modified high-speed temporary storage line (Cache line), causing the high-speed temporary storage line to be written back to the memory ; (8) the temperature, voltage, and bus clock ratio of the microprocessor 100 exceed a respective range; (9) an external trigger signal is generated by a user in an external pin (pin) of the microprocessor 100 established.

Advantageously, since the SPU 2423 independently runs the program code 132 of the core 102, it does not have the same constraints as executing tracer code in the core 102. Thus, the SPU 2423 can detect or be notified of events independent of the instruction execution boundaries of the core 102 and without interrupting the state of the core 102 .

The SPU 2423 has its own program code for execution. The SPU 2423 can fetch its program code from the non-core microcode ROM 2425 or from the non-core PRAM 116 . That is, more preferably, the SPU 2423 shares the microcode running in the core 102 with the uncore ROM 2425 and the uncore PRAM 116 . The SPU 2423 uses the non-core PRAM 116 to store its data, including the log files. In one embodiment, the SPU 2423 also includes its own serial port interface, which can transmit the log file to an external device. Advantageously, the SPU 2423 can also instruct a tracker running on a core 102 to store the log file information from the uncore PRAM 116 into system memory.

The SPU 2423 communicates with the core 102 through state registers and control registers. The SPU status register includes a bit corresponding to each event described above and the SPU 2423 can detect. To notify the SPU 2423 of an event, the core 102 sets a bit in the SPU status register corresponding to the event. Some event bits are set by the microprocessor 100 hardware and some are set by the core 102 microcode. The SPU 2423 reads the status register to determine the list of events that have occurred. A control register includes bits for each operation that the SPU 2423 responds to detecting one of the events specified in the status register. That is, for each possible event in the status register, a set of operation bits exists in the control register. In one embodiment, each event has 16 action bits. In one embodiment, when the status register is written to indicate an event, it causes an interrupt to the SPU 2423 in response to the SPU 2423 reading the status register to determine which events have occurred. Advantageously, this saves power by reducing the need for the SPU 2423 to poll the status register. The status and control registers are also readable and writable by user programs executing instructions (eg, RDMSR and WRMSR instructions).

The set of operations that the SPU 2423 can perform in response to detecting an event includes the following. (1) Write the log file information into the non-core PRAM 116 . For each write operation to a log file, multiple operation bits exist to allow the programmer to specify that only a subset of the particular log file information should be written. (2) Write the log file information from the non-core PRAM 116 to the serial port interface. (3) Write one of the control registers to set an event of the tracker. That is, the SPU 2423 can interrupt a core 102 and cause the tracer microcode to perform a set of operations related to the event. The operation can be specified by the previous user. In one embodiment, when the SPU 2423 writes to the control register to set the event, this causes the core 102 a machine check exception, and the machine check exception handler checks to see if the tracker is enabled. If so, the machine check exception handler transfers control to the tracker. The tracker reads the control register and if the event set in the control register is an event for which the user has enabled the tracker, the tracker performs the operations previously described by the user associated with the event . For example, the SPU 2423 can set an event to cause the tracker to write log file information stored in the uncore PRAM 116 into system memory. (4) Write a control register to cause the microcode to branch to a microcode address specified by the SPU 2423. This is especially helpful if the microcode is in an infinite loop such that the tracer cannot perform any meaningful operations, but the core 102 still executes and retires the instruction, which means the processor is executing event will not occur. (5) Write a control register to reset a core 102 . As mentioned above, the SPU 2423 can detect a core 102 in progress (eg, no instructions have been retired for some programmable amount of time) and reset the core. The reset microcode checks to see if the reset was initiated by the SPU 2423, and if so, during initialization of the core 102, helps write the log file information to system memory before clearing the log file information middle. (6) Record file events continuously. In this mode, rather than waiting for an event to be interrupted, the SPU 2423 spins in a loop that checks the status register, and continuously records information to the non-core PRAM 116, and optionally additionally write the record file information into the serial port interface. (7) Write a control register to stop a core 102 from issuing requests to the shared cache 119 , and/or stop the shared cache 119 from acknowledging requests to the core 102 . This is especially useful in removing memory subsystem related design errors, such as page translation table (tablewalk) hardware errors, which can even be corrected during operation of the microprocessor 100, such as by modifying the SPU 2423 program through a patch code, as described below. (8) Write to the control register of the external bus interface controller of the microprocessor 100 to perform processing in the external system bus, such as specific cycles or memory read/write cycles. (9) Write to a control register of a core 102 programmable interrupt controller, for example, generate an interrupt to another core 102 or simulate an I/O device to the core 102 or fix it in the interrupt controller of a mistake. (10) Write to a control register of the shared cache 119 to control its size, eg, disable or enable the associated shared cache 119 in different ways. (11) Writing control registers of various functional units of the core 102 to configure different performance features, such as branch prediction and data prefetch algorithms. As described below, the SPU 2423 program code can facilitate being patched, causing the SPU 2423 to perform actions as described herein to patch the design even after the microprocessor 100 has been designed and manufactured. defects or perform other functions.

The SPU start address register 2497 holds the address at which to start fetching instructions when the SPU 2423 is removed from reset. The SPU start address register is written by the core 102 . This address can be located in uncore PRAM 116 or in uncore microcode ROM 2425 .

Please refer to FIG. 25 , which is a block diagram showing a microcode patch 2500 according to an embodiment of the present invention. In the embodiment of Figure 25, the microcode patch 2500 includes the following parts: a header 2502; a real-time patch 2504; a checksum (Checksum) 2506 of the real-time patch 2504; a CAM data 2508; a core PRAM patch 2512; A collation 2514 of the CAM data 2508 and core PRAM patch 2512; a RAM patch 2516; a non-core PRAM patch 2518; a collation 2522 of the core PRAM patch 2512 and RAM patch 2516. After the checksum 2506/2514/2522 is loaded into the microprocessor 100, the microprocessor 100 checks the integrity of each part of the patch. More preferably, the microcode patch 2500 is read from system memory and/or a non-volatile system, such as ROM or FLASH memory with a system BIOS or scalable firmware, for example middle. Header 2502 describes the various parts of the patch 2500, such as its size, the location in its respective patch-associated memory where the patched part is loaded, and a valid field indicating whether the part contains a valid patch that applies to the microprocessor 100. Flag.

The live patch 2504 includes program code (e.g., instructions, preferably microcode instructions) to be loaded into the non-core microcode patch RAM 2408 of FIG. 24 (e.g., at block 2612 of FIGS. Executed by core 102 (eg, block 2616 in FIGS. 26A-26B ). The patch 2500 also specifies the address in the patch RAM 2408 at which the immediate patch 2504 is loaded. More preferably, the hotfix 2504 code modifies default values written by the reset microcode, such as values written to configuration registers that affect the configuration of the microprocessor 100 . After the on-the-fly patch 2504 is executed by each core outside the patch RAM 2408, it will not be executed again. In addition, subsequent loading of the RAM patch 2516 into the patch RAM 2408 (eg, block 2632 in FIGS. 26A-26B ) may overwrite the live patch 2504 in the patch RAM 2408 .

The RAM patch 2516 includes patched microcode instructions to replace in the core ROM 2404 or non-core ROM 2425 to be patched. The RAM patch 2516 also includes the address at which the patched microcode instructions were written to the location in the patched RAM 2408 when the patch 2500 was used (eg, at block 2632 in FIGS. 26A-26B ). The CAM data 2508 is loaded into the patch CAM 2439 of each core 102 (eg, at block 2626 in FIGS. 26A-26B ). The above is described from the perspective of the operation of the repair CAM 2439, the CAM data 2508 includes one or more items, and each item includes a pair of microcode extraction addresses. The first address is the fetched microcode instruction and what is matched by the fetched address. The second address points to an address in the patch RAM 2408 that has the patched microcode instructions executed in place of the patched microcode instructions.

Unlike the live patch 2504, the RAM patch 2516 is maintained in the patch RAM 2408 and continues (along with the patch CAM 2439 operations based on patch CAM data 2508) to patch the core microcode ROM 2404 and/or the non-core microcode ROM 2425 until reset by another patch 2500 or the microprocessor 100.

The core PRAM patch 2512 includes the data written to the core PRAM 2499 of each core 102 and the address at which each entry of the data is written into the core PRAM 2499 (eg, at block 2626 of FIGS. 26A-26B ). The uncore PRAM patch 2518 includes the data written to the uncore PRAM 116 and the address at which each entry in the data is written into the uncore PRAM 116 (eg, at block 2632 of FIGS. 26A-26B ).

Please refer to FIGS. 26A-26B , which are a flowchart showing an operation of the microprocessor 100 in FIG. 24 to propagate a microcode patch 2500 of FIG. 25 to the cores 102 of the microprocessor 100 . The operation is described in a single and new perspective, but each core 102 of the microprocessor 100 operates in accordance with the present invention to jointly propagate the microcode patch to all cores 102 of the microprocessor 100 . FIGS. 26A-26B describe the operation of a core encountering the instruction using a modification to the microcode, whose flow begins at block 2602 , and the operation of other cores 102 , whose flow begins at block 2652 . It should be appreciated that fixes 2500 may be applied to microprocessor 100 at different times during operation of microprocessor 100 . For example a first patch 2500 is used according to the atomic embodiments described herein when the system including the microprocessor 100 is booted, such as during BIOS initialization, and a second patch 2500 is used during the operation Used after the system is running, it is especially useful for the purpose of clearing the processor 100 of errors.

In block 2602, one of the cores 102 encounters an instruction instructing it to apply the microcode patch in the microprocessor 100. More preferably, the microcode patching is similar to the microcode patching described above. In one embodiment, the application microcode patch instruction is an x86WRMSR instruction. In response to the application microcode patch instruction, the core 102 disables interrupts and prevents execution of the microcode of the application microcode patch instruction. It should be understood that the system software including the application microcode patching instruction may include a sequence of instructions in preparation for the microcode patching application. More preferably, however, as a response to the sequence of single architectural instructions, the microcode patch is propagated atomically to all cores at the architectural instruction level. That is, once interrupts are disabled in the first core 102 (e.g., in block 2602, the core 102 encounters the apply microcode patch instruction), when executing microcode propagates the microcode patch and applies to When all cores 102 of the microprocessor 100 (e.g., until after block 2652), interrupts remain disabled; furthermore, once disabled in other cores 102 (e.g., at block 2652), they are still disabled Use until the microcode patch has been applied to all cores 102 of the microprocessor 100 (eg, until after block 2634). Thus, advantageously, the microcode patch is propagated atomically at the architectural instruction level and applied to all cores 102 of the microprocessor 100 . Flow proceeds to block 2604.

In block 2604, the core 102 takes ownership of the hardware semaphore 118 in FIG. 1 . More preferably, the microprocessor 100 includes a hardware semaphore 118 associated with the patched microcode. More preferably, the core 102 acquires ownership of the hardware semaphore 118 in a manner similar to that described above in FIG. 20 , more specifically blocks 2004 and 2006 . The hardware semaphore 118 is used because it is possible that one of the cores 102 uses a patch 2500 in response to encountering an application microcode patch instruction, and a second core 102 encounters an application microcode patch instruction as the response to the application microcode patch instruction. The second core will start using the second patch 2500, which may cause incorrect execution, for example, due to misuse of the first patch 2500. Flow proceeds to block 2606.

In block 2606 , the core 102 sends a patch message to the other core 102 and sends an inter-core interrupt to the other core 102 . More preferably, the core 102 prevents the microcode from responding to the apply microcode patch instruction (block 2602) during the period in which time interrupts are disabled (e.g., the microcode does not allow itself to be interrupted), or in response to the Interrupt (block 2652), and remain in the microcode until block 2634. Flow proceeds from block 2606 to block 2608 .

In block 2652, one of the other cores 102 (e.g., a core other than the core 102 that encountered the apply microcode patch instruction in block 2602) is interrupted and the inter-core interrupt to receive the patch information. In one embodiment, the core 102 fetches the interrupt in the next architectural instruction boundary (eg, in the next x86 instruction boundary). In response to the interrupt, the core 102 disables interrupts and prevents the microcode from processing the patch information. As mentioned above, although the flow in block 2652 is described from the perspective of a single core 102, every other core 102 (e.g., the core 102 not in block 2602) is interrupted in block 2652 and receives the information , and the steps at block 2608 to block 2634 are performed. Flow proceeds from block 2652 to block 2608 .

In block 2608, the core 102 writes a synchronization request for a synchronization condition 21 (indicated as SYNC 21 in FIGS. 26A-26B ) into its synchronization register 108, and the control unit 104 puts the core 102 into sleep state, and subsequently woken up by the control unit 104 when all cores 102 have written to SYNC 21 . The process proceeds to decision block 2611.

In decision block 2611, the core 102 determines whether it is the core 102 that encountered the microcode patch in block 2602 (compared to a core 102 that received the patch information in block 2652). If so, the process proceeds to block 2612; otherwise, the process proceeds to block 2614.

In block 2612 , the core 102 loads a portion of the live patch 2504 of the microcode patch 2500 into the non-core patch RAM 2408 . Additionally, the core 102 generates a checksum of the loaded live patch 2504 and verifies that it matches the checksum 2506 . More preferably, the core 102 also sends information to the other cores 102 indicating the length of the immediate patch 2504 and the location in the non-core patch RAM 2408 where the immediate patch 2504 is loaded. Advantageously, since all cores 102 are known to execute the same microcode that implements the microcode patch application, when a previous RAM patch 2516 exists in the non-core patched RAM 2408, then due to the time period (assuming it was implemented on the microcode) The microcode of the code patching application is not patched) there will be no hits in the patched CAM 2439, so it is safe to overwrite the non-core patched RAM 2408 with the new patch. In another embodiment, the core 102 loads the immediate patch 2504 into the uncore PRAM 116, and before the instant patch 2504 in block 2616 is executed, the core 102 copies the immediate patch 2504 from the uncore PRAM 116 to The non-core patched RAM 2408. More preferably, the core 102 loads the immediate patch into a portion of the uncore PRAM 116 that is reserved for this purpose, e.g., a portion of the uncore PRAM 116 that is not used for other purposes, such as holding the values used by the microcode (e.g., core 102 state, TPM state, or effective microcode constants as described above), and a portion of the non-core PRAM 116 may be patched (e.g., at block 2632) so that any The previous non-core PRAM patch 2518 was not clobbered. In one embodiment, the act of loading or copying by the uncore PRAM 116 is performed in multiple stages to reduce the required size of the reserved portion. Flow proceeds to block 2614.

In block 2614, the core 102 writes a synchronization request of a synchronization condition 22 (indicated as SYNC 22 in FIGS. 26A-26B ) to its synchronization register 108, and the control unit 104 puts the core 102 into a sleep state , and then wake up by the control unit 104 when all cores 102 write a SYNC 22 . Flow proceeds to block 2616.

In block 2616 , the core 102 executes the on-the-fly patch 2504 in the non-core patch RAM 2408 . As described above, in one embodiment, the core 102 copies the live patch 2504 from the uncore patch RAM 116 to the uncore patch RAM 2408 before the core 102 executes the live patch 2504 . Flow proceeds to block 2618.

In block 2618, the core 102 writes a synchronization request of a synchronization condition 23 (indicated as SYNC 23 in FIGS. 26A-26B ) to its synchronization register 108, and the control unit 104 puts the core 102 into a sleep state , and then wake up by the control unit 104 when all cores 102 write a SYNC 23 . The process proceeds to decision block 2621.

In decision block 2621, the core 102 determines whether the core 102 is the core 102 that encountered the apply microcode patch instruction in block 2602 (compared to a core 102 that received the patch information in block 2652). If so, the process proceeds to block 2622; otherwise, the process proceeds to block 2624.

In block 2622 , the core 102 loads the CAM data 2508 and core PRAM patch 2512 into the uncore PRAM 116 . Additionally, the core 102 generates a checksum of the loaded CAM data 2508 and core PRAM patch 2512 and verifies that it matches the checksum 2514 . More preferably, the core 102 also transmits information to the other cores 102 indicating the length of the CAM data 2508 and core PRAM patch 2512, and the location in the uncore PRAM 116 where the CAM data 2508 and core PRAM patch 2512 are loaded . More preferably, the core 102 loads the CAM data 2508 and core PRAM patch 2512 into a reserved portion of the uncore PRAM 116 so that any previous uncore PRAM patch 2518 is not clobbered, similar to In the manner described in block 2612. Flow proceeds to block 2624.

In block 2624, the core 102 writes a synchronization request of a synchronization condition 24 (indicated as SYNC 24 in FIGS. 26A-26B ) to its synchronization register 108, and the control unit 104 puts the core 102 into a sleep state , and then wake up by the control unit 104 when all cores 102 write a SYNC 24 . Flow proceeds to block 2626.

In block 2626 , the core 102 loads the CAM data 2508 from the uncore PRAM 116 into its patched CAM 2439 . Additionally, the core 102 loads the core PRAM patch 2512 from the uncore PRAM 116 into its core PRAM 2499 . Advantageously, since all cores are known to be executing the same microcode implemented in the microcode patch application, even if the corresponding RAM patch 2516 has not yet been written to the non-core patch RAM 2408 (which would occur in block 2632), due to the During this period (assuming the microcode implemented in the microcode patch application is not patched) there will be no hits in the patch CAM 2439, so it is safe to load the patch CAM 2439 using the CAM data 2508 . Furthermore, since all cores 102 are known to be executing the same microcode implemented in the microcode patch application, and interrupts will not be used in any core 102 until the patch 2500 is propagated to all cores 102, the core PRAM patch Any updates performed by 2512 to the core PRAM 2499, including updates to change values (e.g., feature settings) that may affect the operation of the core 102, are guaranteed not to be seen in the architecture until the patch 2500 has been propagated up to all cores 102. Flow proceeds to block 2628.

In block 2628, the core 102 writes a synchronization request of a synchronization condition 25 (labeled as SYNC 25 in FIGS. 26A-26B ) to its synchronization register 108, and the control unit 104 puts the core 102 into a sleep state , and then wake up by the control unit 104 when all cores 102 write a SYNC 25 . The process proceeds to decision block 2631.

In decision block 2631, the core 102 determines whether the core 102 is the core 102 that encountered the apply microcode patch instruction in block 2602 (compared to a core 102 that received the patch information in block 2652). If so, the process proceeds to block 2632; otherwise, the process proceeds to block 2634.

In block 2632 , the core 102 loads the RAM patch 2516 into the non-core patch RAM 2408 . Additionally, the core 102 loads the uncore PRAM patch 2518 into the uncore PRAM 116 . In one embodiment, the uncore PRAM patch 2518 includes program code executed by the SPU 2423 . In one embodiment, the uncore PRAM patch 2518 includes updates to the values used by the microcode, as described above. In one embodiment, the uncore PRAM patch 2518 includes updates to the SPU 2423 program code and values used by the microcode. Advantageously, since all cores 102 are known to be executing the same microcode implemented in the microcode patch application, more specifically, the patch CAM 2439 of all cores 102 has been loaded with the new CAM data 2508 (e.g., in block 2626), and during this period (assuming the microcode implemented in the microcode patch application is not patched) there will be no hits in the patch CAM 2439. Furthermore, since all cores 102 are known to be executing the same microcode implemented in the microcode patch application, and interrupts will not be used in any core 102 until the patch 2500 is propagated to all cores 102, the non-core PRAM patch 2518 Any updates performed to the uncore PRAM 116, including updates to change values (e.g., feature settings) that may affect the operation of the core 102, are guaranteed not to be seen in the architecture until the fix 2500 has been propagated to all Core 102 so far. Flow proceeds to block 2634.

In block 2634, the core 102 writes a synchronization request for a synchronization condition 26 (labeled as SYNC 26 in FIGS. 26A-26B ) to its synchronization register 108, and the control unit 104 puts the core 102 into a sleep state , and then wake up by the control unit 104 when all cores 102 write a SYNC 26 . Flow ends at block 2634.

After block 2634, if program code is loaded into the uncore PRAM 116 for the SPU 2423, the patch core 102 then also begins executing the program code, as described in FIG. Additionally, after block 2634 , the patch core 102 releases the hardware semaphore 118 obtained in block 2634 . Further, after block 2634, the core 102 re-enables the aforementioned interrupt.

Please refer to FIG. 27, which is a timing diagram showing an example of the operation of a microprocessor according to the flowcharts of FIGS. 26A-26B. In this example, a microprocessor 100 is configured with three cores 102, labeled Core 0, Core 1, and Core 2, as shown. However, it should be understood that in other embodiments, the microprocessor 100 may include a different number of cores 102 . In this timing diagram, the sequence of events proceeds as described below.

Core 0 receives a request to patch microcode (per block 2602) and in response fetches the hardware semaphore 118 (per block 2604). Core 0 then sends a microcode patch message and interrupt to Core 1 and Core 2 (each block 2606). Core 0 then writes a SYNC 21 and goes to sleep (per block 2608).

Each Core 1 and Core 2 is eventually interrupted from its current task and reads the information (each block 2652). To this end, Core 1 and Core 2 each write a SYNC 21 and go to sleep (each block 2608). As shown, each core may write to SYNC 21 at a different time, for example due to delays in executing the instruction when the interrupt is asserted.

When all cores have written to SYNC 21, the control unit 104 wakes up all cores simultaneously (per block 2608). Core 0 then loads the live patch 2504 into the uncore PRAM 116 (per block 2612), writes a SYNC 22, and goes to sleep (per block 2614). Each core 1 and core 2 writes a SYNC 22 and goes to sleep (each block 2614).

When all cores have written to the SYNC 22, the control unit 104 wakes up all cores simultaneously (per block 2614). Each core executes the live patch 2504 (per block 2616) and writes a SYNC 23, and goes to sleep (per block 2618).

When all cores have written to the SYNC 23, the control unit 104 wakes up all cores simultaneously (per block 2618). Core 0 then loads the CAM data 2508 and core PRAM patch 2512 into the uncore PRAM 116 (per block 2622), writes a SYNC 24, and goes to sleep (per block 2624).

When all cores have written to the SYNC 24, the control unit 104 wakes up all cores simultaneously (per block 2624). Each core then loads its patch CAM 2439 with the CAM data 2508, loads its core PRAM 2499 with the core PRAM patch 2512 (each block 2626), writes a SYNC 25, and goes to sleep (each block 2626) block 2628).

When all cores have written the SYNC 25, the control unit 104 wakes up all cores simultaneously (per block 2628). Core 0 then loads the RAM patch 2516 into the uncore patch RAM 2408, loads the uncore PRAM patch 2518 into the uncore PRAM 116, writes a SYNC 26, and goes to sleep (per block 2634).

When all cores have written to the SYNC 26, the control unit 104 wakes up all cores simultaneously (per block 2634). As mentioned above, if the program code has been loaded into the non-core PRAM 116 for the SPU 2423 in the step of block 2632, the core 102 also then starts to execute the program code, as described in FIG. 30 below.

Please refer to FIG. 28 , which is a block diagram showing a multi-core microprocessor 100 according to another embodiment. The microprocessor 100 is similar in many respects to the microprocessor 100 of FIG. 24 . However, the microprocessor 100 of FIG. 28 does not include an uncore patch RAM, but includes a core patch RAM 2808 in each core 102 that provides similar functionality to the uncore patch RAM 2408 of FIG. 24 . However, the core patch RAM 2808 in each core 102 is dedicated to its respective core 102 and is not shared with other cores 102 .

Please refer to FIGS. 29A-29B , which are flowcharts illustrating an operation of the microprocessor 100 in FIG. 28 for propagating a microcode patch to the cores 102 of the microprocessor 100 according to another embodiment. In another embodiment of FIG. 28 and FIGS. 29A-29B , the patch 2500 of FIG. 25 can be modified so that the collation 2514 uses the RAM patch 2516 instead of the core PRAM patch 2512, and in the CAM data 2508 After the integrity of the core PRAM patch 2512 and the RAM patch 2516 are loaded into the microprocessor 100 (e.g., block 2922 in FIGS. 29A-29B ), the microprocessor 100 is enabled to verify the integrity of the CAM data 2508 properties, the core PRAM patch 2512 and the RAM patch 2516. The flowchart of Figures 29A-29B is similar in many respects to the flowchart of Figures 26A-26B, and like numbered blocks are also similar. However, block 2912 replaces block 2612 , block 2916 replaces block 2616 , block 2922 replaces block 2622 , block 2926 replaces block 2626 , and block 2932 replaces block 2632 . In block 2912, the core 102 loads the live patch 2504 into the uncore PRAM 116 (instead of loading into an uncore patch RAM). In block 2916, the core 102 copies the immediate patch 2504 from the uncore PRAM 116 to the core patch RAM 2808 before executing the immediate patch 2504. In block 2922 , the core 102 loads the RAM patch 2516 into the uncore PRAM 116 in addition to the CAM data 2508 and the core PRAM patch 2512 . In block 2926, the core 102, in addition to loading the CAM data 2508 from the uncore PRAM 116 into its patch CAM 2439 and loading the core PRAM patch 2512 from the uncore PRAM 116 into its core PRAM 2499, the core 102 The RAM patch 2516 is also loaded from the uncore PRAM 116 into its patch RAM 2808 . In block 2932, unlike block 2632 of Figures 26A-26B, the core 102 does not load the RAM patch 2516 into a non-core patch RAM.

It can be observed from the above examples that the atomic propagation of the microcode patch 2500 benefiting from propagation to each associated memory 2439/2499/2808 of the microprocessor 100 core 102 and to associated non-core memory 2408/116 proceeds in a manner to ensure the The integrity and validity of the patch 2500, even if there are multiple concurrently executing cores 102, can share resources that would otherwise clobber parts of another core's patch when applied in a conventional manner.

patch service processor code

Please refer to FIG. 30 , which is a flow chart showing how the microprocessor 100 of FIG. 24 is used to patch a service processor program code. Flow begins at block 3002.

In block 3002, the core 102 loads the program code executed by the SPU 2423 into the uncore PRAM 116 at a patch address specified by a patch, as described above at block 2632 in FIGS. 26A-26B . The process enters the block 3004.

In block 3004 , the core 102 controls the SPU 2423 to execute the program code at the patched address, eg, the address where the SPU 2423 program code was written in the uncore PRAM 116 in block 3002 . In one embodiment, the SPU 2423 is configured to fetch its reset vector from the start address register 2497 (e.g., the address at which the SPU 2423 starts fetching instructions after removing reset), and the core 102 the patch Addresses are written to the start address register 2497, followed by a control register that causes the SPU 2423 to be reset. Flow proceeds to block 3006.

In block 3006 , the SPU 2423 begins fetching program code (eg, fetching its first instruction) at the patch address, eg, writing the SPU 2423 program code to the address in uncore PRAM 116 in block 3002 . Typically, the SPU 2423 patch code residing in the uncore PRAM 116 will perform a jump to the SPU 2423 program code residing in the uncore ROM 2425 . Flow ends at block 3006.

The ability to patch the SPU 2423 code may be particularly useful. For example, the SPU 2423 may be used for performance testing that is transient in nature, for example, it may not be desirable for the performance testing SPU 2423 program code to be a permanent part of the microprocessor 100, but only part of the developmental portion, For example, for the manufacturing part, only become part of the development part. In another example, the SPU 2423 can be used to find and/or repair errors. In another example, the SPU 2423 can be used to configure the microprocessor 100 .

Atomic propagation of updates to per-core real-time architecture visible storage resources

Please refer to FIG. 31 , which is a block diagram showing a multi-core microprocessor 100 according to another embodiment. The microprocessor 100 is similar in many respects to the microprocessor 100 of FIG. 24 . However, each core 102 of the microprocessor 100 in FIG. 31 also includes architecturally visible memory type range registers (Memory Type Range Registers, MTRRs) 3102 . That is, each core 102 instantiates an architecturally visible MTRR 3102, even if system software requires the MTRR 3102 to be consistent across all cores 102 (described in more detail below). MTRR 3102 is an example of per-core instantiation of architecturally visible storage resources, and other per-core instantiation of architecturally visible storage resource embodiments are described below. (Although the figure is not shown, each core 102 also includes the core PRAM 2499, core microcode ROM 2404, patch CAM 2439 in Figure 24, and in one embodiment, the core microcode patch RAM 2808 of Figure 28 ).

MTRR 3102 provides system software to associate a memory type with a plurality of different physical address ranges in the microprocessor 100 system memory address space. Examples of different memory types include strong uncacheable, uncacheable, write-combining, write through, write back, and write-protected ( write protected). Each MTRR 3102 specifies (explicitly or implicitly) a memory range and its memory type. The common values for each MTRR 3102 define a memory map that specifies the memory types of different memory ranges. In one embodiment, the MTRR3102 is similar to that described in Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3: System Programming Guide, September 2013, particularly Section 11.11, which is incorporated herein by reference and form part of this manual.

It is desirable that the memory map defined by MTRR 3102 be the same in all cores for the microprocessor 100 so that the software running in the microprocessor 100 has a memory coherency. However, in conventional processors, there is no hardware support to maintain the consistency of MTRRs among the cores of a multi-core processor. As mentioned earlier in the note at the bottom of pages 11-20 of Book 3 of the Intel Manual, "P6 and more recent processor families do not provide hardware support for maintaining [the consistency of MTRRs values]". System software is therefore responsible for maintaining cross-core MTRR consistency. Section 11.11.8 of the Intel manual cited above describes an algorithm for system software to maintain consistency and update its MTRRs relative to each core of a multi-core processor, eg, all cores execute instructions to update their respective MTRRs.

Conversely, the system software can update the MTRR 3102 in one of the cores 102 for each instance, and facilitate the core 102 to propagate the update to the MTRR 3102 in all cores 102 of the microprocessor 100 in an atomic fashion. Embodiments of the respective requests are described herein (similar to the manner described above for the implementation of a microcode patch by the embodiments in FIGS. 24-30 ). It provides a method to maintain architectural instruction level consistency between MTRR 3102 of different cores 102 .

Please refer to FIG. 32 , which is a flowchart showing the operation of the microprocessor 100 in FIG. 31 for propagating an MTRR 3102 update to one of the cores 102 of the microprocessor 100 . The operation is described from the perspective of a single core, but each core 102 of the microprocessor 100 operates according to the description of co-propagating the MTRR3 102 update to all cores 102 of the microprocessor 100 . More specifically, FIG. 32 describes the operation of the core encountering the instruction to update the MTRR 3102 , whose flow begins at block 3202 , and the operation of the other cores 102 , whose flow begins at block 3252 .

In block 3202, one of the cores 102 encounters an instruction instructing the core to update its MTRR 3102. That is, the MTRR update command includes an MTRR 3102 identifier and an update value written into the MTRR 3102 . In one embodiment, the MTRR update instruction is an x86WRMSR instruction, which is used to specify the update value in the EAX:EDX register and the MTRR3102 identifier in the ECX register, which is in the core 102 An MSR address within the MSR address space. In response to the MTRR update instruction, the core 102 disables interrupts and prevents execution of the MTRR update instruction's microcode. It should be understood that the system software including the MTRR update command may include a multi-command sequence in preparation for the MTRR 3102 update. More preferably, however, the MTRRs 3102 of all cores 102 are updated atomically at the architectural instruction level in response to the sequence of single architectural instructions. That is, once interrupts are disabled in the first core 102 (e.g., in block 3202, the core 102 encounters the MTRR update instruction), when executing microcode propagates new MTRR 3102 values to the microprocessor When all cores 102 are 100 (eg, until after block 3218), interrupts remain disabled. Furthermore, once disabled in other cores 102 (e.g., at block 3252), it remains disabled until the MTRR 3102 of all cores 102 of the microprocessor 100 has been updated (e.g., until after block 2634) . Thus, advantageously, the new MTRR 3102 value is propagated atomically to all cores 102 of the microprocessor 100 at the architectural instruction level. Flow proceeds to block 3204.

In block 3204, the core 102 takes ownership of the hardware semaphore 118 in FIG. 1 . More preferably, the microprocessor 100 includes a hardware semaphore 118 associated with an MTRR 3102 . More preferably, the core 102 acquires ownership of the hardware semaphore 118 in a manner similar to that described above in FIG. 20 , more specifically blocks 2004 and 2006 . The hardware semaphore 118 is used because it is possible that one of the cores 102 performs a MTRR 3102 update in response to encountering a MTRR update command, while a second core 102 encounters a MTRR update command as the second The core will start updating the MTRR3102's response, which may cause incorrect execution. Flow proceeds to block 3206.

In block 3206, one core 102 sends an MTRR update message to the other core 102 and sends the other core 102 an inter-core interrupt. More preferably, the core 102 prevents the microcode from responding to the MTRR update instruction (in block 3202) or in response to the Interrupted (in the block 3252), and maintained in the microcode until block 3218. Flow proceeds to block 3208.

In block 3252, one of the other cores 102 (e.g., a core other than the core 102 that encountered the MTRR update instruction in block 3202) is interrupted and interrupted by the inter-core interrupt transmitted in block 3206 The MTRR update information is received. In one embodiment, the core 102 fetches the interrupt in the next architectural instruction boundary (eg, in the next x86 instruction boundary). In response to the interrupt, the core 102 disables interrupts and blocks the microcode that processes the MTRR update information. As mentioned above, although the flow in block 3252 is described in terms of a single core 102, every other core 102 (e.g., the core 102 not in block 3202) is interrupted in block 3252 and receives the information , and the steps at block 3208 to block 3234 are performed. Flow proceeds from block 3252 to block 3208 .

In block 3208, the core 102 writes a synchronization request (labeled as SYNC 31 in FIG. 32 ) of a synchronization condition 31 into its synchronization register 108, and the control unit 104 causes the core 102 to enter the sleep state, And then wake up by this control unit 104 when all cores 102 have written to SYNC 31 . The process proceeds to decision block 3211.

In decision block 3211, the core 102 determines whether it is the core 102 that encountered the MTRR update command in block 3202 (compared to a core 102 that received the MTRR update message in block 3252). If so, the process proceeds to block 3212; otherwise, the process proceeds to block 3214.

In block 3212 , the core 102 loads the uncore PRAM 116 with the MTRR identifier specified by the MTRR update instruction and an MTRR update value in which the MTRR is updated so that all other cores 102 can see. In the case of an x86 embodiment, MTRR 3102 includes: (1) a repaired range MTRR that includes a single 64-bit MSR updated via a single WRMSR instruction and (2) a different range MTRR that includes two 64-bit MSRs, Each MSR is written by a different WRMSR instruction, eg, the two WRMSR instructions specify different MSR addresses. For different range MTRRs, one of the MSRs (the PHYSBASE register) includes a base address of the memory range and a type field for specifying the memory type, and the other MSR (the PHYSMASK register) Contains a valid bit and a mask field for setting the range mask. More preferably, the updated MTRR value loaded by the core 102 into the uncore PRAM 116 is as follows.

1. If the MSR is determined to be the PHYSMASK register, then the core 102 loads the non-core PRAM 116-128 bit update value, which includes the new 64-bit value specified by the WRMSR instruction (it includes the effective bits and mask values) and the current value of the PHYSBASE register (which includes base and type values).

2. If the MSR is determined to be the PHYSBASE scratchpad:

a. If the active bit is being set in the PHYSMASK register, the core 102 loads into the non-core PRAM 116 a 128-bit update value including the new 64-bit value specified by the WRMSR instruction (the 64-bit value includes the base value and type value) and the current value of the PHYSMASK register (the current value includes the valid bit and mask value).

b. If the active bit is being set in the PHYSMASK register, the core 102 loads into the non-core PRAM 116 a 64-bit update value that includes only the new 64-bit value specified by the WRMSR instruction value (the 64-bit value includes the base and type values).

Additionally, the core 102 sets a flag in the non-core PRAM 116 if the updated value written is a 128-bit value, and clears the core 102 if the updated value is a 64-bit value. Flag. Flow proceeds from block 3212 to block 3214.

In block 3214, the core 102 writes a synchronization request of a synchronization condition 32 (marked as SYNC 32 in FIG. 32 ) to its synchronization register 108, and the control unit 104 causes the core 102 to enter the sleep state, and then When all cores 102 write a SYNC 32, they are woken up by the control unit 104. Flow proceeds to block 3216.

In block 3216 , the core 102 reads the MTRR 3102 identifier and the MTRR update value written in block 3212 from the uncore PRAM 116 . Advantageously, this MTRR update value propagation is performed in an atomic fashion such that any update to the MTRR 3102 that might affect the operation of the respective core 102 is guaranteed to be architecturally invisible until the update value has been propagated to the MTRR 3102 of all cores 102 So far, since all cores are known to be executing the same microcode implemented in the MTRR update instruction, and interrupts will not be used in any core 102 until the update value is propagated to all cores 102's respective MTRR 3102. As described in block 3212 in the present embodiment above, if the flag is set in block 3212, then the core 102 also updates (in addition to the determined MSR) the PHYSMASK or PHYSBASE register; otherwise, if the When the flag is clear, the core 102 only updates the determined MSR. Flow proceeds to block 3218.

In block 3218, the core 102 writes a synchronization request of a synchronization condition 33 (indicated as SYNC 33 in FIG. 32 ) to its synchronization register 108, and the control unit 104 causes the core 102 to enter a sleep state, and then When all cores 102 write a SYNC 33, they are woken up by the control unit 104. Flow ends at block 3218.

After block 3218 , the MTRR core 102 releases the hardware semaphore 118 obtained in block 3204 . Further, after block 3218, the core 102 restarts interrupts.

It can be seen from FIG. 31 and FIG. 32 that the system software running in the microprocessor 100 in FIG. 31 can be beneficial to execute an MTRR update instruction in the single core 102 of the microprocessor 100 to complete the update of all the cores 102 of the microprocessor 100. The specified MTRR 3102, rather than individually executing an MTRR update instruction in each core 102, can provide system integrity.

One specific MTRR 3102 instantiated in each core 102 is a System Management Range Register (SMRR) 3102 . Since the SMRR 3102 has program codes and data operations related to the System Management Mode (SMM), such as a System Management Interrupt (SMI) processor, the memory range specified by the SMRR 3102 is Called the SMRAM area. When a program code running in a core 102 attempts to access the SMRAM area, if the core 102 is running in SMM, the core 102 only allows this access; otherwise, the core 102 ignores a write to the SMRAM area. Write, and restore a fixed value for each bit read from the SMRAM area. Additionally, if a core 102 running in the SMM attempts to execute code outside of the SMRAM area, the core 102 will assert a machine check exception. In addition, the core 102 only allows program code to be written into the SMRR 3102 when the core 102 is running in SMM. This facilitates the protection of SMM program code and data in this SMRAM area. In one embodiment, the SMRR3102 is similar to that described in Intel64 and IA-32 Architectures Software Developer's Handbook Volume 3: System Programming Guide, September 2013, particularly Sections 11.11.2.4 and 34.4.2.1, which are in It is cited herein and constitutes a part of this specification.

In general, each core 102 has its own instance of SMM program code and data in memory. It is desirable that the SMM code and data of each core 102 be protected not only from code running in itself, but also from code running in another core 102 . To accomplish this using SMRRs 3102, system software typically places multiple instances of SMM code and data in contiguous blocks in memory. That is, the SMRAM region is a single contiguous memory region containing all instances of SMM program code and data. If the SMRR 3102 of all cores 102 of the microprocessor 100 has a value specifying the entirety of the single contiguous memory region including all instances of SMM code and data, this can prevent code running on one core in non-SMM from updating another An example of SMM program code and data of a core 102. When a window of time exists where SMRRs 3102 have different values in cores 102, for example, the microprocessor 100 has different values for SMRRs 3102 in different cores 102, any value of which is definitely less than a single value that includes all instances of SMM program code and data. Adjacent to the entirety of the memory region, the system may be vulnerable to a security attack, which may be severe given the nature of SMMs. Accordingly, embodiments describing atomically propagated updates to SMRRs 3102 may be particularly advantageous.

In addition, other embodiments contemplate that updates to the architecturally visible storage resources of each other instance of the microprocessor 100 are propagated in an atomic manner similar to the method described above. For example, in one embodiment, each core 102 instantiates certain bit fields of the x86IA32_MISC_ENABLE MSR, and a WRMSR executed in a core 102 is propagated to the microprocessor in a manner similar to that described above All cores 102 in 100. Furthermore, embodiments also contemplate execution in a core 102 of a WRMSR to other MSRs instantiated in all cores 102 of the microprocessor 100, both architectural and specific and/or current and future , is propagated to all cores 102 in the microprocessor 100 in a manner similar to that described above.

Additionally, although embodiments describe the per-core instantiation architecture-visible storage resources as MTRRs, other embodiments contemplate that the per-core instantiation resources are resources other than x86 ISA instruction set architecture resources, and others in addition to MTRRs resource. For example, other resources besides MTRRs include CPUID values and MSRs for reporting functions, such as Vectored Multimedia eXtensions (VMX) functions.

Although the present invention has been disclosed above with preferred embodiments, it is not intended to limit the present invention. Those skilled in the art may make some changes and modifications without departing from the spirit and scope of the present invention. Therefore, the protection of the present invention The scope shall be defined by the claims of the present application. For example, software may enable, eg, function, manufacture, model, simulate, describe and/or test the devices and methods described herein. The above can be realized by using general programming languages (for example: C, C++), hardware description languages (Hardware Description Languages, HDL) including Verilog HDL, VHDL and so on. Such software may be contained in a physical medium in the form of program code, such as any other machine-readable (such as computer-readable) storage medium such as a semiconductor, magnetic disk, hard disk or optical disk (such as: CD-ROM, DVD-ROM etc.), wherein, when the program code is loaded and executed by a machine, such as a computer, the machine becomes a device for implementing the present invention. The method and device of the present invention can also be transmitted in the form of program code through some transmission media, such as wires or cables, optical fibers, or any transmission mode, wherein when the program code is received, loaded and executed by a machine such as a computer , the machine becomes an apparatus for implementing the present invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique device that operates similarly to application-specific logic circuits. The device and method described in the present invention can be included in a semiconductor intellectual property core such as a microprocessor core (embedded in HDL), and converted into an integrated circuit hardware product. Furthermore, the apparatus and methods described in the present invention may comprise physical embodiments having a combination of hardware and software. Therefore, the scope of protection of the present invention shall be defined by the claims of the present application. Finally, those skilled in the art may make some modifications and modifications based on the concepts and specific embodiments disclosed in the present invention without departing from the spirit and scope of the present invention so as to achieve the same purpose of the present invention.

Claims (16)

1. A microprocessor, characterized in that, comprising: a plurality of processing cores configured to operate in a first mode and a second mode, In the above-mentioned first mode, each processing core of the above-mentioned plurality of processing cores jointly operates as a boot processor and jointly executes an instance of a respective test program; and In the second mode, only a single processing core of the plurality of processing cores operates as the boot processor and executes the test of the microprocessor. 2. The microprocessor according to claim 1, further comprising: a plurality of interrupt controllers corresponding to the plurality of processing cores, wherein each interrupt controller includes an indication for determining whether to specify an interrupt request for the corresponding processing core, In the above-mentioned first mode, each processing core of the above-mentioned plurality of processing cores sets an indication in a corresponding interrupt controller to a value related to the above-mentioned boot processor. 3. The microprocessor according to claim 1, wherein the microprocessor is further configured to modify the higher address bits of the memory accessed by each processing core of the plurality of processing cores, so that each Handles core access to a separate address space. 4. The microprocessor of claim 1, wherein a reserved register of the microprocessor specifies the first mode or the second mode of operation of the plurality of processing cores. 5. The microprocessor of claim 4, wherein the reserved register is configured to receive a sensed evaluation of a blown or unblown fuse. 6. The microprocessor of claim 4, wherein the reserved register is configured to receive a value specifying the first mode or the second mode from a boundary scan input. 7. The microprocessor according to claim 1, wherein each processing core of the plurality of processing cores is configured to determine the first mode or the second mode in response to a reset of the processing core. 8. The microprocessor according to claim 1, wherein, in the first mode, the plurality of processing cores are configured to be set in the respective registers of each processing core in the plurality of processing cores flag to indicate that the processing core is the above-mentioned boot processor. 9. A method for configuring a multi-core microprocessor, characterized in that said method comprises: determining the mode of said microprocessor; When the above-mentioned mode is the first mode, each processing core of the plurality of processing cores of the above-mentioned microprocessor jointly operates as a guide processor, and each processing core of the above-mentioned plurality of processing cores jointly executes a respective test program instance of ; and When the above mode is the second mode, only a single processing core of the plurality of processing cores operates as the boot processor and executes the test of the microprocessor. 10. The method according to claim 9, wherein the microprocessor further includes a plurality of interrupt controllers corresponding to the plurality of processing cores, wherein each interrupt controller includes an indication, and the indication is used to determine whether to target Corresponding to the processing core specified interrupt request, In the above-mentioned first mode, each processing core of the above-mentioned plurality of processing cores sets an indication in a corresponding interrupt controller to a value related to the above-mentioned boot processor. 11. The method of claim 9, further comprising: Modifying higher address bits of the memory accessed by each processing core of the plurality of processing cores, so that each processing core accesses a separate address space. 12. The method of claim 9, wherein a reserved register of the microprocessor specifies the first mode or the second mode of operation of the plurality of processing cores. 13. The method of claim 12, wherein the retention register is configured to receive a sensed evaluation of a blown or unblown fuse. 14. The method of claim 12, wherein the reserved register is configured to receive a value specifying the first mode or the second mode from a boundary scan input. 15. The method of claim 9, wherein the step of determining a mode is performed in response to a reset of said processing core. 16. The method according to claim 9, wherein, in the first mode, a flag is set in a respective register of each processing core among the plurality of processing cores to indicate that the processing core is the boot processor.