JP5372929B2 - Multi-core processor with hierarchical microcode store - Google Patents

Abstract

A multiple-core processor having a hierarchical microcode store. A processor may include multiple processor cores, each configured to independently execute instructions defined according to a programmer-visible instruction set architecture (ISA). Each core may include a respective local microcode unit configured to store microcode entries. The processor may also include a remote microcode unit accessible by each of the processor cores. Any given one of the processor cores may be configured to generate a given microcode entrypoint corresponding to a particular microcode entry including one or more operations to be executed by the given processor core, and to determine whether the particular microcode entry is stored within the respective local microcode unit of the given core. In response to determining that the particular microcode entry is not stored within the respective local microcode unit, the given core may convey a request for the particular microcode entry to the remote microcode unit.

Description

  The present invention relates to processors, and more particularly to microcode implementation within a processor that includes a multiprocessor core.

  As processor implementation progresses, attempts to increase processor performance by duplicating individual processor cores within the processor are becoming increasingly popular. Such a core may be capable of independent instruction execution while increasing coarse-grained parallelism, and this coarse-grained parallelism is intended to improve performance, such as increasing the frequency of fine-grained parallelism or execution. It can be used to run applications with lower cost of resistance and lower design complexity than might otherwise be required.

  However, the implementation of a multi-core processor has some design issues in the implementation itself. Certain processor core resources, such as microcode routine storage resources, may be included in the critical timing path, so the proximity of a resource to a given core directly affects the operating frequency of a given core Sometimes. For this reason, if a single instance of such a storage resource is shared among a plurality of cores, the waiting time for the shared instance becomes long, which may lead to a decrease in core performance. However, duplicating storage resources such that each core contains its own instance of the resource can also be costly in terms of design area, power, and / or other design figure of merit.

  Various embodiments of a multi-core processor having a hierarchical microcode store are disclosed. According to one embodiment, the processor may include a plurality of processor cores that are configured to independently execute instructions defined in accordance with a programmable instruction set architecture (ISA). Each of the processor cores may each include a local microcode unit configured to store a microcode entry. The processor may also include a remote microcode unit including a remote microcode store that is accessible by each of the processor cores and configured to store microcode entries. Any core of the processor core generates a given microcode entry point corresponding to a particular microcode entry that includes one or more operations performed by the given processor core, and each of the given processor core May be configured to determine whether a particular microcode entry is stored in the local microcode unit. In response to determining that a particular microcode entry is not stored in each local microcode unit, the given core may communicate a request for the particular microcode entry to the remote microcode unit. .

  While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. However, the drawings and detailed description are not intended to limit the invention to the particular form disclosed, but rather, the invention is intended to be as defined by the appended claims. It should be understood that all modifications, equivalents, and alternatives within the spirit and scope are encompassed.

FIG. 3 is a block diagram illustrating one embodiment of a processor core. 1 is a block diagram illustrating one embodiment of a processor that includes a multiprocessor core. FIG. The block diagram which shows the structure of one embodiment of a microcode control store. 1 is a block diagram illustrating one embodiment of a hierarchical microcode store that includes local and remote microcode units. FIG. FIG. 3 is a block diagram illustrating one embodiment of a local microcode unit. The block diagram which shows one Embodiment of a remote microcode unit. 6 is a flow diagram illustrating one embodiment of a method for retrieving a microcode entry in a processor having a hierarchical microcode store. 1 is a block diagram illustrating one embodiment of an exemplary computer system.

Overview of Processor Core FIG. 1 illustrates one embodiment of a processor core 100. Generally speaking, the core 100 may be stored in a system memory coupled directly or indirectly to the core 100. The instructions may be configured to execute. Such instructions may be defined according to a specific instruction set architecture (ISA). For example, the core 100 may be configured to implement the x86 ISA series, but in other embodiments, the core 100 may implement different ISAs or combinations of ISAs.

  In the illustrated embodiment, the core 100 may include an instruction cache (IC) 110 coupled to an instruction fetch unit (IFU) 120. The IFU 120 may be coupled to a branch prediction unit (BPU) 130 and an instruction decode unit 140. The decode unit 140 may be coupled to provide operations to a plurality of integer operation execution clusters 150 a-b and a floating point unit (FPU) 160. Each of the clusters 150a-b may include a cluster scheduler 152a-b coupled to each of the plurality of integer arithmetic execution units 154a-b. In various embodiments, the core 100 may include a data cache (not shown) either in or shared with the clusters 150a-b. In the illustrated embodiment, the FPU 160 may be coupled to receive operations from the FP scheduler 162. The clusters 150a-b, the FPU 160, and the instruction cache 110 may be further coupled to a core interface unit 170. The core interface unit 170 may further include a system interface unit (SIU) that is external to the L2 cache 180 and the core 100. interface unit) (shown in FIG. 2 and described below). FIG. 1 reflects certain specific instruction and data flow paths between various units, but may be given additional paths or directions of data or instruction flow not shown in detail in FIG. Please note that it is good. Further, for example, a further configuration of the core 100 that adopts a change in the number of instances of the cluster 150, the FPU 160, and the L2 cache 180 and a change in the mutual relationship between the units is also possible.

  As described in further detail below, the core 100 may be configured for multi-threaded execution that can simultaneously execute instructions from a Coco execution thread. It should be noted that in various embodiments, different numbers of threads may be supported for concurrent execution, and different numbers of clusters 150 and FPUs 160 may be provided. In addition, other shared or multi-threaded units may be added that include special media processors or other types of accelerators.

  The instruction cache 110 may be configured to store instructions before they are fetched, decoded, and issued for execution. In various embodiments, the instruction cache 110 may be configured as a direct map, set associative, or fully associative cache of any suitable size and / or association. The instruction cache 110 may be physical addressing, virtual addressing, or a combination of the two. In some embodiments, instruction cache 110 may also include translation lookaside buffer (TLB) logic configured to cache virtual / physical translations of instruction fetch addresses, although TLB and Translation logic may also be included elsewhere in the core 100.

  Instruction fetch access to the instruction cache 110 may be coordinated by the IFU 120. For example, the IFU 120 may track the current program counter state of various execution threads and issue fetches to the instruction cache 110 to retrieve additional execution instructions. In the case of an instruction cache miss, either instruction cache 110 or IFU 120 may coordinate the fetching of instruction data from L2 cache 180. In some embodiments, the IFU 120 may also adjust prefetching of instructions from other levels of memory hierarchy prior to predicted use to mitigate the effects of memory latency. For example, successful instruction prefetching may increase the likelihood of instructions residing in the instruction cache 110 when needed, thus avoiding cache miss latency effects at multiple levels of the memory hierarchy. .

  Various types of branches (eg, conditional or unconditional jumps, call / return instructions, etc.) may change the execution flow of a particular thread. Branch prediction unit 130 may generally be configured to predict future fetch addresses for use by IFU 120. In some embodiments, the BPU 130 may include any suitable structure configured to store information regarding branch instructions. For example, in some embodiments, the BPU 130 may include one or more different types of predictor variables (eg, local, global, or hybrid predictor variables) configured to predict the outcome of a conditional branch.

  As a result of fetching, the IFU 120 may be configured to generate an instruction byte sequence, sometimes referred to as a fetch packet. The length of the fetch packet may be any suitable number of bytes. In some embodiments, particularly for ISAs that implement variable length instructions, there are a variable number of valid instructions aligned within a given fetch packet, and in some instances, instructions in different fetch packets Sometimes. Generally speaking, decode unit 140 decodes or transforms instructions into operations suitable for execution by cluster 150 or FPU 160 and identifies instruction boundaries in fetch packets to send such execution operations. May be configured.

  In one embodiment, DEC 140 may initially be configured to determine the length of possible instructions within a given window of bytes extracted from one or more fetch packets. For example, for an x86 compatible ISA, the DEC 140 is configured to identify a valid prefix, opcode, “mod / rm” and “SIB” byte valid sequence starting at each byte position within a given fetch packet. Further, the pick logic in the DEC 140 may be configured to identify the boundaries of multiple valid instructions in a window in one embodiment, In one embodiment, multiple fetch packets and A plurality of instruction pointer groups that specify instruction boundaries may be queued in the DEC 140.

  Next, an instruction may be directed from the Fett packet storage to one of several instruction decoders in the DEC 140. In one embodiment, the DEC 140 may be configured to provide as many independent instruction decoders as instructions dispatched every execution cycle, although other configurations are possible and contemplated. In embodiments where the core 100 supports microcoded instructions, each instruction decoder may be configured to determine whether a given instruction is microcoded, provided that it is microcoded. , A microcode engine operation for converting an instruction into an operation sequence may be invoked. Alternatively, the instruction decoder may convert the instructions into a single operation (or, in some embodiments, multiple operations in some embodiments) suitable for execution by the cluster 150 or FPU 160. The resulting operations, sometimes called micro-operations, micro-OPs, or μOPs, may be stored in one or more queues to wait for execution dispatch. In some embodiments, microcode operations and non-microcode (or “fast path”) operations may be stored in separate queues. Further details regarding embodiments of microcode implementation within the core 100 are described in further detail below.

  The dispatch logic in DEC 140 may be configured to examine the status of queued operations waiting for dispatch, in combination with the status of execution resources and dispatch rules, in order to attempt to assemble the dispatch parcel. For example, the DEC 140 may determine the availability of operations in the dispatch queue, the number of operations queued in the cluster 150 and / or FPU 160 and waiting to be executed, and any resources that may be applied to the dispatched operations. Constraints may be taken into account. In one embodiment, DEC 140 may be configured to dispatch a parcel of operations to one of cluster 150 or FPU 160 during a given execution cycle.

  In one embodiment, the DEC 140 may be configured to decode and dispatch operations to only one thread during a given execution cycle. However, it should be noted that IFU 120 and DEC 140 need not operate simultaneously in the same thread. Various types of thread switching methods are contemplated for use during instruction fetch and decode. For example, IFU 120 and DEC 140 may be configured to select different threads for processing every N cycles in a round-robin fashion (where N may be only 1). In other forms, thread switching may be affected by dynamic conditions that occur during the operation.

  Generally speaking, cluster 150 may be configured to implement integer and logical operations and perform load / store operations. In one embodiment, each of the clusters 150a-b may be for performing operations on a respective thread. Each cluster 150 may include its own scheduler 152, which may be configured to manage issues for performing operations already dispatched to the cluster. Each cluster 150 may further include a copy of the integer physical register file and completion logic (eg, a reorder buffer or other structure for managing the completion and exit of operations).

  Within each cluster 150, an execution unit 154 may support simultaneous execution of a variety of different types of operations. For example, in one embodiment, execution unit 154 may support simultaneous load / store address generation (AGU) operations and arithmetic / logic (ALU). Execution unit 154 may support additional operations such as integer multiplication and division, but in various embodiments, cluster 150, along with such additional operations, throughput and concurrent of other ALU / AGU operations. Scheduling constraints may be implemented. In various embodiments, the cluster 150 may include or share a data cache that may be organized differently than the instruction cache 110.

  The FPU 160 may include an FP scheduler 162 that may be configured to receive, queue, and issue execution operations within the FP execution unit 164, such as the cluster scheduler 152. The FPU 160 may also include a floating point physical register file configured to manage floating point operands. The FP execution unit 164 may be configured to implement various types of floating point operations as may be defined by the ISA. In various embodiments, the FPU 160 may support the concurrent execution of certain different types of floating point operations and may support different precisions (eg, 64-bit operands, 128-bit operands, etc.). In various embodiments, the FPU 160 may include a data cache or may be configured to access a data cache located in other units.

  The instruction cache 110 and the data cache 156 may be configured to access the L2 cache 180 via the core interface unit 170. In one embodiment, the CIU 170 may provide a general-purpose interface between the core 100 and other cores 100 in the system, external system memory, peripheral devices, and the like. Typically, the capacity of the L2 cache 180 is substantially larger than the first level instruction and data cache.

  In some embodiments, the core 100 may support in-order operations. In other embodiments, the core 100 may support out-of-order execution of operations including load and store operations. That is, the execution order of the operations in the cluster 150 and the FPU 160 may be different from the initial program order of the instructions to which the operations correspond. By ordering such relaxation operations, more efficient scheduling of execution resources may be performed, thereby improving the overall execution performance.

  Furthermore, the core 100 may implement various control and data speculation techniques. As described above, the core 100 may implement various branch prediction and speculative prefetch techniques to attempt to predict the direction in which the thread execution control flow will proceed. Such control speculation techniques may generally attempt to provide a consistent instruction flow before it is certain that an instruction is available or that an error speculation has occurred (eg, due to branch error prediction). . If a control error speculation occurs, the core 100 may be configured to discard operations and data along the error speculation path and redirect the execution control to the correct path. For example, in one embodiment, the cluster 150 may be configured to execute a conditional branch instruction and determine whether the branch result matches the predicted result. If not, the cluster 150 may be configured to be redirected to the IFU 120 to begin fetching along the correct path.

  Alternatively, core 100 may implement various data speculation techniques that attempt to provide data values for use in further execution before the data values are known to be accurate. By using such data speculatively, timing constraints necessary for evaluating all conditions related to the validity of the data before using the data are relaxed, and the core operation can be speeded up.

  In various embodiments, a processor implementation may include multiple instances of the core 100 made as part of a single monolithic integrated circuit chip along with other structures. FIG. 2 shows one such embodiment of a processor. As shown, the processor 200 includes four core instances 100a-d, each of which may be configured as described above. In the illustrated embodiment, each of the cores 100 may be coupled to an L3 cache 220 and a memory controller / peripheral interface unit (MCU) 230 via a system interface unit (SIU) 210. . In one embodiment, the L3 cache 220 is configured as a unified cache implemented using any suitable scheme that operates as an intermediate cache between the core 100 L2 cache 180 and the relatively slow system memory 240. Also good.

  MCU 230 may be configured to interface processor 200 directly with system memory 240. For example, the MCU 230 may be a dual data rate synchronous dynamic RAM (DDR SDRAM), a DDR-2 SDRAM, a fully buffered dual inline memory module (FB-DIMM), or Configured to generate the signals necessary to support one or more different types of random access memory (RAM), such as another suitable type of memory that may be used to implement system memory 240. May be. System memory 240 may be configured to store instructions and data that may be computed by various cores 100 of processor 200. The contents of system memory 240 are cached by various of the caches described above. Also good.

  Further, the MCU 230 may support other types of interfaces to the processor 200. For example, the MCU 230 may be used to coordinate a processor 200 that may include another graphics processor, graphics memory, and / or other components with a graphics processing subsystem. A dedicated graphics processor such as an (AGP: Accelerated / Advanced Graphics Port) interface version may be implemented. The MCU 230 may also be configured to implement one or more types of peripheral interfaces, eg, a version of the PCI-Express bus standard, through which the processor 200 may be configured as a storage device, graphics device, networking device. You may link with peripheral devices, such as a device. In some embodiments, a secondary bus bridge (eg, “south bridge”) external to processor 200 is used to couple processor 200 to other peripheral devices via other types of buses or interconnects. May be. Although the memory controller and peripheral interface functions are shown integrated within the processor 200 via the MCU 230, in other embodiments, these functions are implemented in the processor 200 via a conventional “north bridge” arrangement. Note that it may be implemented externally. For example, the various functions of the MCU 230 may be implemented via a different chipset than those that may be integrated within the processor 200.

Local and Remote Microunits As described above, in some embodiments, core 100 may support microcoded operations. Generally speaking, microcode is a control that separates from the general programmable visible path of instruction flow where individual operations performed by a given core 100 may be provided, for example, by IFU 120. It is from a data store and may include processor implementation technology. As an example, a given ISA, such as the x86 ISA, may include highly complex instructions and other predetermined processor behavior (eg, reset function, interrupt / trap / exception function, etc.). A simple shift or rotate instruction with register operands can be very simple to implement as a single operation that can be performed directly by execution unit 154. For example, a rotate instruction that rotates an operand through a carry flag may be more easily implemented as a combination of different operations that can be performed within the execution unit 154. Certain complex control transfer instructions, instructions that modify system registers such as control registers, instructions with virtual memory, and even more complex instructions such as instructions that execute within the content of a priority or protection model coordinate instruction execution It may be accompanied by additional operations, such as a test of the processor state (e.g. priority state) being performed.

  Some instructions in the ISA may map directly to individual corresponding operations. In some embodiments, if these complex instructions of the ISA do not map directly to a single operation that can be executed within the execution unit 154, a given complex instruction may be dispatched for execution. Microcode may be used to convert to a better and simpler sequence of operations. The set of operations available for microcode may generally include operations corresponding to directly executable ISA instructions. However, in some embodiments, microcode operations may include operations that can be performed by an execution unit 154 that is not programmer-visible. Further, microcode may be used to generate an executable sequence of operations in response to a processor event that defines an architecture that does not correspond to a particular instruction in the implementation ISA. For example, the reset microcode routine may include an operation sequence configured to place the core 100 in a consistent operation state after a software or hardware reset event (eg, cache initialization, specific architecture and For example, storing a specific value in a non-architectural register, or an instruction fetch starting from a given address). In some embodiments, microcode may also be used to generate routines that perform non-architectural functions of core 100 (ie, in general, functions are performed by a programmer during normal operations of cell 100 or Neither visible nor accessible). For example, microcode is used to implement hardware testing or debug routing to use instruction microcode for product manufacturing, field analysis, power-on self-testing, or other suitable applications. Also good.

  The microcode routine is typically any suitable type of control store such as read only memory (ROM) or writable memory such as random access memory (RAM), as described in more detail below. May be stored within. In FIG. 3, one exemplary scheme of a microcode control store is shown. In the illustrated embodiment, the microcode control store 300 includes a plurality of entries 310, each of which includes a number of calculation fields 320 and a sequence control field 330. In one embodiment, each of the entries 310 may correspond to a respective entry point in the microcode address space. For example, a 12-bit microcode address space may allow as many as 4,096 (4K) distinct entry point values. In some embodiments, the microcode address space may be configured such that there are more possible entry point values than the actual entry 310, such as when less dense entry point addressing is employed. Please note that.

  In one embodiment, each operation field 320 of entry 310 may be configured to store information that encodes a single operation that can be performed by one of execution units 154. For example, the operation field 320 includes an opcode bit configured to identify the type of operation to be performed and an operand bit configured to identify an operand source used by the operation, such as a register or value data. May be included. In some embodiments, the operand encoding in the operation field 320 is taken from the operand from a microinstruction (eg, a programmable ISA instruction fetched by the IFU 120) in response to the microcode entry 310 being executed. It may be specified that it should be done. In some embodiments, different fields of the computation field 320 may correspond to each of the execution units 154 in the cluster 150. Thus, for example, if execution unit 154 includes two ALUs and two AGUs, two of operation fields 320 may correspond to ALUs and two may correspond to AGUs. . That is, each operational field 320 of a given entry 310 may correspond to a respective issue slot of the cluster, and thus the entire given entry 310 may be dispatched as a unit to the cluster 150. In some cases, one operation in a given entry 310 may have a dependency on another operation in the same entry, whereas each operation in entry 310 is independent of the others. It may be a thing. It should be noted that in other embodiments, there may be no issue slot limit for the calculation field 320 in the microcode entry 310. For example, in one such embodiment, operations may be issued from any field 320 to any execution unit.

  The sequence control field 330 may be configured to govern the sequencing behavior of the microcode routine. For example, the sequence control field 330 may be configured to indicate the exit point of the routine (ie, the entry 310 where the particular routine ends), or a micro such as a conditional or unconditional branch or jump to a different entry point. A non-continuous change in code flow control may be indicated. In some embodiments, the microcode sequence control may be sent in a pipeline so that the sequence control field 330 associated with a given entry 310 is actually associated with a different consecutive predecessor entry 310. For example, in an embodiment that has a one or two cycle delay or bubble between the fetch of microcode entry 310 and the execution of sequence control field 330 associated with entry 310, the behavior of entry 310 is affected at entry point N. A sequence control field 330 may be stored in association with entry 310 at each entry point N-1 or N-2.

  In some embodiments, instruction decode unit 140 may include functions related to accessing and sequencing microcode entry 310. For example, DEC 140 may be configured to detect instructions and other processor events that require microcode execution and request entry 310 from the microcode store accordingly. In some embodiments, the DEC 140 calculates an entry point that depends on the instruction or other event for which the microcode is needed, eg, by mapping an instruction opcode to an entry point value in the space of the microcode address. It may be configured as follows. The DEC 140 may then submit the calculated entry points to a microcode unit that may be included in the DEC 140 or provided as a separate functional unit in the core 100, resulting in an execution Operations shown in one or more microcode entries 310 may be retrieved and dispatched. Microcode entry points may also occur in response to events other than instruction decode. For example, an entry point may be generated by an execution cluster or other unit in response to detecting an exception or interrupt.

  In embodiments of the processor 200 that include multiple cores 100, a particular consideration is the microcode implementation. Typically, each core 100 will reference the same microcode content (eg, as reflected in entry 310. That is, in some embodiments, each core 100 is The same ISA may be implemented and the code may generally be expected to execute with the same functional behavior regardless of the executing core 100. Accordingly, the core 100 may be implemented in an embodiment of the processor 200. May be configured to share a single common instance of a microcode store that includes all of the microcode entries 310 defined for it, however, such as a single ROM structure shared by all cores 100, etc. By implementing a single control store instance, you can proceed to the core 100 that requested the data from the control store. The longer the distance that the microcode data is required, the longer the overall waiting time required to perform the operation involving the microcode, which means that the execution performance of the core 100 is degraded. Can be invited.

  Furthermore, if a plurality of cores 100 attempt to access the shared control store simultaneously by supplying a single control store among the plurality of cores 100, a resource contention problem may occur. Increasing the number of concurrent accesses supported by the control store (for example, increasing the number of read buses, the amount of entry point decoding logic, etc.) increases the complexity and cost of the control store and decreases timing performance On the other hand, serializing simultaneous access requests can increase the waiting time of microcode access received by the core 100 when each core waits for the order of services.

  In contrast, an instance of a microcode control store may be replicated so that each core 100 contains a complete copy of the microcode. Such duplication may improve the routing, latency, and resource contention problems described above for the core 100 sharing a single control store instance. For example, each replica instance is placed relatively close to the respective core 100, thereby reducing the overall routing distance. However, duplicating the control store as a whole in this way increases the design area and complexity of each of the cores 100, which can increase the design and manufacturing costs, as well as the power consumption of the processor 200.

  In some embodiments, the processor 200 may be configured to employ a hierarchical microcode control store approach that includes both replication and sharing aspects. As shown in FIG. 4, in one embodiment, each of the plurality of cores 100a-d of the processor 200 includes a respective instance of a local microcode unit 400a-d (or briefly, the local unit 400a-d). The shared remote microcode unit 410 (or simply remote unit 410) may be configured to be accessed via the system interface unit 210. Although omitted for clarity, it should be noted that other elements of the processor 200 shown in FIG. 2 may be included in the embodiment of FIG. Further, in various embodiments, the number of cores 100 and each local microcode unit 400 included in the cores may vary. In some embodiments, the local unit 400 may be included within other units of the respective core 100. For example, the local unit 400 may be implemented in the DEC 140. In the illustrated embodiment, each of the cores 100 includes a local microcode unit 440, but in some embodiments, only a plurality of cores 100 of the core 100 have local microcode units 400. May not be included. That is, not all cores 100 are required to be configured identically for local unit 400, but in some embodiments, the same configuration may be required.

  Generally speaking, each instance of the local microcode unit 400 may be configured to store a microcode routine that is determined so that the operation of the core 100 is more performance sensitive, while The code unit 410 may be configured to store microcode routines determined to have low performance sensitivity. For example, a given microcode routine may be selected for storage in the local unit 400 if it meets the performance sensitivity threshold requirement, otherwise it is assigned for storage in the remote unit 410. Also good.

  In various embodiments, the performance sensitivity of a given microcode routine may be determined using different criteria. For example, the length of a microcode routine may be used as a measure of performance sensitivity so that a routine of a given length that is less than or equal to the threshold length (eg, a routine consisting of a single entry 310) Routines included in the local unit 400 but longer than the threshold length are included in the remote unit 410. In some cases, a routine execution queue may be used as a substitute for length. In other forms, routine execution frequency may be used as a selection criterion, so routines that are executed at least with a threshold frequency or probability (eg, predictable by simulation of predicted programming workload). Are included in the local unit 400 and routines with lower frequency or probability of execution are included in the remote unit 410. In other embodiments, in determining the storage location of a given routine, both execution frequency / probability and the length of the routine may be considered, along with other criteria. For example, reset microcode routines are very long and may not execute frequently, so they are candidates that may be included in the remote microcode unit 410. In other cases, microcode routines that handle virtual memory page misses may be executed more frequently than reset routines. However, the page miss routine may have a high possibility of performing a large number of memory accesses with a long waiting time due to a page miss. In this way, the waiting time for accessing the page miss routine may be inferior to the waiting time for executing the routine, and thus can be a candidate included in the remote microcode unit 410. Generally speaking, for threshold requirements, the performance sensitivity of a given microcode routine is one or more of the above factors (eg, length of execution, latency, frequency) or other related factors. May be any suitable function.

  FIG. 5 illustrates one embodiment of an instance of the local microcode unit 400. In the illustrated embodiment, the local unit 400 includes a control store 500 and a sequencer 510. Generally speaking, the control store 500 is an instance of a microcode control store 300 configured to store a plurality of microcode entries 310 corresponding to microcode routines selected to be included in the local unit 400. It may be an example. In one embodiment, the control store 500 may include a ROM configured with any suitable scheme. For example, the control store 500 may be organized as a single large ROM bank, as multiple banks separated according to the fields of the entry 310, or in another suitable manner. Generally speaking, the ROM is configured to receive an index value (eg, entry point) as input and output an output value (eg, entry 310) corresponding to the supplied input value in response thereto. Any type of addressable data structure may be referenced. Such data structures may include arrangements of memory and gate arrays, or other suitable logic devices. In some embodiments, the control store 500 may include writable memory elements such as RAM or non-volatile memory in addition to or in place of the ROM.

  The sequencer 510 may be configured to access the control store 500 according to the microcode request received from the DEC 140 and the sequence control information included in the entry 310 in one embodiment. In response to receiving a particular microcode entry point from DEC 140, sequencer 510 may be configured to access control store 500 to retrieve entry 310 corresponding to the particular entry point. The operation specified in the retrieved entry 310 may then be returned to the DECI 140 for dispatch and execution. In addition, the sequencer 510 determines a discontinuous entry point (e.g., an entry point specified in the sequence control field 330) to determine whether to retrieve another entry 310 that follows the previously retrieved entry 310. To evaluate the sequence control field 330 of the retrieved entry 310, to retrieve another entry 310 located at), to terminate retrieval of the microcode entry 310, or to take some other predetermined action. May be configured. In some embodiments, the microcode entry 310 may include branch operations that may be predicted and / or executed in the execution unit 154 or elsewhere in the core 100. In some such embodiments, the sequencer 510 may be configured to respond to changes in microcode sequence control that result from a predicted or performed branch operation. For example, such a branch operation may cause the sequencer 510 to redirect the microcode fetch from the current entry point to the entry point specified by the branch operation.

  In some embodiments, each of the local microcode units 400 is configured to map the same set of microcode entry points to a respective control store 500 so that each of the cores 100 is a local entry point. The same entry point may be accessed. In some embodiments, each instance of the control store 500 may have the same content as each other instance in the various cores 100 of the processor 200, but in other embodiments, the content of each control store 500 May not need to be exactly the same as the others. For example, functional differences may occur between instances of the control store 500 that may be correctable due to manufacturing defects, patch technology, or by referring to an entry 310 stored elsewhere than a given control store 500. There is also.

  FIG. 6 shows one embodiment of the remote microcode unit 410. In the illustrated embodiment, the remote unit 410 includes a remote microcode unit interface 610 that may be configured to communicate with the core 100 via the SIU 210 or via any other suitable type of interface. Interface 610 may be coupled to request queue 620 and send queue 630. Request queue 620 may be configured to carry requests for microcode entries stored in the control store to remote control store 640. In the illustrated embodiment, the remote control store 640 may include any number of microcode ROM banks 650a-n, and may optionally include a microcode patch RAM 660. In some embodiments, request queue 620 may also be configured to carry a microcode request to any dynamic microcode RAM array 670. The send queue 630 may be configured to queue entries retrieved from the remote control store 640 and, in some embodiments, from the dynamic microcode RAM array 670 for sending to these request cores 100. Good.

  As described above with respect to FIG. 4, the remote unit 410 may be configured to store various microcode routines instead of the core 100. Such routines may include, for example, routines that are long, infrequently executed, or considered less likely to affect processor performance than routines selected for inclusion in local unit 400. Generally speaking, the remote unit 410 may be configured to receive requests for various microcode entry points from different cores of the core 100 and respond to each request with one or more corresponding entries. Good. Depending on the configuration of the remote microcode unit interface 610 and the interface protocol employed between the core 100 and the remote unit 410, microcode requests from multiple cores 100 may be received concurrently or serially.

  Remote control store 640 is an exemplary instance of microcode control store 300 configured to store a number of microcode entries 310 corresponding to microcode routines selected to be included in remote unit 410. May be. In some embodiments, the format of the entry 310 stored in the remote control store 640 may be similar to that of the entry 310 stored in the control store 500 of the local unit 400. In the illustrated embodiment, entries 310 may be distributed across multiple microcode ROM banks 650 according to any suitable division or organization. Note that in other embodiments, the number of blanks 650 may vary. Also, like the control store 500, it is contemplated that in some embodiments, the remote control store 640 may include writable memory and / or data storage elements in addition to the memory array.

  In general, the remote microcode unit interface 610, the request queue 620, and the transmission queue 630 may be collectively configured to manage the processing of microcode requests retrieved from the core 100. Request queue 620 may be configured to store incoming microcode requests, and in one embodiment, these requests can be processed in entry point and request core 100 until they can be processed in remote control store 640. Minimal display may be included. Similarly, the send queue 630 retrieves entries 310 retrieved from the remote control store 640 or, in some embodiments, from the dynamic microcode RAM array 670 until the entries 410 can be sent to their requesting cores 100. It may be configured to store. In one embodiment, remote microcode unit interface 610 includes management of request queue 620 and transmit queue 630 to control the receipt of requests from core 100 and the transmission of resulting entries to core 100. May be configured. Interface 610 also selects request queues 620 for processing, for example, in response to a sequence control or arbitration scheme, and adjusts storage in transmit queue 630 for entries retrieved during request processing. May include logic configured to coordinate the processing of individual requests stored in the. In other embodiments, selection of requests for processing from request queue 620 and storage of results in send queue 630 may be performed by logic external to interface 610.

  Many different requirement management configurations of the remote unit 410 are possible and contemplated. In one embodiment, the remote unit 410 may omit the sequence function. In such embodiments, the remote microcode unit interface 610 may be configured to receive requests from a given core 100 corresponding to each particular entry point that the given core 100 desires to receive. Thus, for example, the sequencer 510 of a given local unit 400 determines which entry points need to be retrieved for a given routine stored in the remote unit 410 and sends it to the control store 500. It may be configured to generate requests directed to those entry points in a manner similar to that used to access.

  Omitting the sequencing function from the remote unit 410 can simplify the design, but can also increase the request traffic and processing latency between the core 100 and the remote unit 410. In other embodiments, remote unit 410 may support varying degrees of spontaneous sequence. For example, in one embodiment, the received microcode request may specify a start entry point and an end entry point or the number of entries to be retrieved. In such an embodiment, the remote unit 410 is configured to retrieve a plurality of entries 310 corresponding to the received request, starting from the start endpoint and continuing sequentially until the end entry point or number of entries to be retrieved is reached. May be. The plurality of entries 310 thus retrieved may be returned to the requesting core 100 in the order in which they were retrieved.

  In another embodiment, the remote unit 410 may support more advanced sequencing functions. For example, the remote unit 410 may be configured to include a sequencer that is functionally similar to the sequencer 510. Such a sequencer may be configured to support some or all values of the sequence control field 330 supported by the sequencer 510. Alternatively, in one embodiment, the sequence function in the remote unit 410 is configured such that the entry 310 stored in the remote unit 410 is configured to include an additional sequence control field that is separate from the sequence control field 330. Additional sequence control fields may be processed by, while sequence control field 330 may be processed by sequencer 510 within a particular local unit 400. In such an embodiment, the task of ordering multiple entry routines may be appropriately divided between the remote unit 410 and the local unit 400.

  Because the remote unit 410 may be shared by many different cores 100, the remote unit 410 may employ a variety of different types of arbitration or scheduling schemes when selecting which microcode request is served. May be configured. For example, the remote unit 410 selects requests from the request queue 620 for processing in a round robin manner, by first selecting the oldest request or by using any other suitable selection scheme. It may be configured as follows. In some embodiments where the remote unit 410 supports request ordering, it is also possible to exclude requests from other cores 100 and retrieve multiple entries 310 with a single request from a particular core 100. is there. Accordingly, in some embodiments, such a request may be interrupted after a certain number of entries 310 have been retrieved so that they can serve different requests. In other forms, the fairness algorithm for selecting the next request to serve may consider not only the latest request served on behalf of the core 100, but also the duration of these requests. Note that in some embodiments, the remote control store 640 may be configured to be multi-ported so that two or more microcode requests may be retrieved simultaneously. For example, the remote control store 640 may be implemented using multiport memory cells. In other configurations, smaller single-port memory cells may be employed in a bank fashion so that multiple requests targeting different banks 650 may be retrieved simultaneously. In some banked embodiments, multiple requests targeting the same bank 650 may be serialized.

  Dividing the microcode implementation hierarchically into multiple local microcode units 400 and shared remote microcode units 410 may improve the timing and power consumption of the processor 200. For example, since the local microcode unit 400 may typically have a smaller area than the remote microcode unit 410, each local microcode unit 400 is as large as each remote microcode unit 410. It can be calculated more frequently than when it is large. Similarly, smaller microcode units typically consume less power than larger ones. In some embodiments, implementing a remote microcode unit 410 separate from the local microcode unit 400 can cause the remote microcode unit 410 to power down when not accessed by the core 100 (eg, a gating clock). Or by disabling the power grid to the remote unit 410). This can reduce the total power consumption of the processor 200.

  FIG. 7 illustrates one embodiment of a method for retrieving a microcode entry 310 in an embodiment of a processor that includes a local microcode unit 400 within an individual core 100 and a shared remote microcode unit 410. In the illustrated embodiment, the operation begins at block 700 where a microcode entry point occurs within a given core 100. In one embodiment, the DEC 140 may, for example, decode the various portions of the instruction, determine that the instruction corresponds to microcode, and generate a corresponding entry point from the decoded instruction. May be configured to generate a microcode entry point corresponding to the instruction received from. As noted above, in some embodiments, reset events, interrupts, traps, exceptions, faults, requests to invoke non-hierarchical microcode routines (eg, test and debug routines), or others that involve execution of microcode Entry points may be generated by DEC 140 or another unit within core 100 for processor events other than instruction execution, such as these types of events.

  Next, it is determined whether the generated entry point is located in the local microcode unit 400 in a given core 100 or corresponds to the entry 310 located in the remote microcode unit 410 (block 702). . In one embodiment, the microcode address space that includes entry 310 has one or more address space portions corresponding to entry 310 in local microcode unit 400, but one or more other separate address spaces. The portion may be split to correspond to the entry 310 in the remote microcode unit 410. For example, one embodiment may support a 12-bit microcode address space that includes 4,096 entries 310, of which 1,024 are located in the local microcode unit 400 and the rest May be stored remotely. In this example, the 16 advance entry point values 0x000 to 0x3FF may correspond to the entry 310 in the local unit 400, and the entry point values 0x400 to 0xFFF may correspond to the entry in the remote unit 410. Other mappings are possible, such as mappings where discontinuities in the microcode address space are assigned to various units. Also, in some embodiments, the determination of whether an entry point is local or remote may depend on an indication other than whether the entry point is in a specific address range. For example, a local / remote display may be decoded from an instruction by a DEC 140 separate from the entry point for that instruction. In various embodiments, the determination of whether an entry point is local or remote is determined by decoding logic in the core 100, such as the DEC 140, by a local microcode unit 400, such as the sequencer 510, or in the core 100. It may be executed by other logic.

  If the entry point that occurred corresponds to an entry 310 located in the local unit 400, the entry is retrieved from the local unit (block 704). For example, upon retrieving an entry point with a microcode request indication, the sequencer 510 in the local unit 400 may be configured to access the control store 500 to retrieve the corresponding entry 310.

  If the entry point that occurred corresponds to an entry 310 located in the remote unit 410, the request may be conveyed to the remote unit (block 706). For example, either the DEC 140 or the local unit 400 may initiate a request to the remote unit 410 by carrying the request through the system interface unit 210 that specifies the remote unit 410 as the destination. The remote unit 410 may then receive the specified entry 310 (block 708) and return the entry to the given core 100 (block 710). For example, remote microcode unit interface 610 may receive a request from SIU 210 and place it in request queue 620. Once selected, the request may be processed to retrieve the specified entry 310 from the remote control store 640 and the result may be placed in the send queue 630. Subsequently, interface 610 may select entry 310 from transmit queue 630 and transport the entry to a given core 100 via SIU 210.

  Once the entry 310 is retrieved from either the local unit 400 or the remote unit 410, the operation may be dispatched for execution (block 712). For example, DEC 140 may dispatch operations as specified in entry 310 to scheduler 152 in one of clusters 150 for subsequent execution by execution unit 154. In some embodiments, further decoding of the operation specified in entry 310 may be performed before being dispatched by DEC 140, for example.

  In some embodiments, the operation specified by the retrieved microcode entry 310 may be stored or queued before being dispatched for execution. For example, DEC 140 may implement a queue that can decouple dispatch of operations from a decoder or microcode fetch process, which may reduce the performance impact of stalls that may occur at DEC 140 or upstream thereof. In some embodiments, operations specified in microcode entry 310 retrieved from remote microcode unit 410 may be inserted directly into such a computation queue or storage upon receipt by core 100 and retrieved. The entered entry 310 may or may not be stored in the core 100. However, in other embodiments, the retrieved remote storage entry 310 may be kept in the core 100 for a certain amount of time, and reused without waiting for it to be retrieved again from the remote unit 410. can do. For example, the local microcode unit 400 may include writable storage that may be written when the entry 310 retrieved from the remote unit 410 is received. In one embodiment, such storage may include one or more buffers or registers, and entry 310 may be stored until it is relegated by subsequently retrieved entry 310.

  In another embodiment, the local unit 400 may include a microcode cache implemented as part of the control store 500, for example. Such a cache may be configured to store a plurality of retrieved entries 310 and is organized using any suitable configuration such as a direct map method, a set associative method, a full associative method, etc. Also good. Cache eviction may be performed according to any suitable replacement policy, such as a least frequently used policy or a long unused policy. In one variation of such an embodiment, the retrieved entry 310 may be stored in the instruction cache 110 rather than in a dedicated microcode cache. In embodiments where remotely stored fetched entries 310 may be cached or stored in the core 100, is the cache or other local storage prior to the occurrence of a request for a given entry 310? Or the presence of a given remote stored entry 310 may be checked either at the same time as the occurrence. If the desired entry 310 is already available in the local cache or other local storage, a request to the remote unit 410 may not be generated, or if already desired, it may be canceled. The microcode cache may be configured to provide a dynamic microcode store that is local to the core 100 and allocated based on a particular instruction stream executing a given core 100. Since the latency of the remote microcode unit 410 may typically be longer than a given local microcode unit 400, the microcode cache is frequently used for remote microcode units 410 when sequences occur. Performance problems with low frequency instruction sequences that may require access can be mitigated.

  In an embodiment such as FIG. 4, a single remote microcode unit 410 may be shared by multiple cores 100, but in other embodiments the remote microcode unit 410 may be replicated. Please keep in mind. For example, some instances of the remote microcode unit 410 may be shared by fewer cores than the entire core 100. In other forms, a complete replica of the remote microcode unit 410 may be included in each core 100. In such an embodiment, the increased area required by replication of the remote microcode unit 410 may be offset by reducing routing and / or timing complexity. For example, duplication of the remote microcode unit 410 may shorten the average distance from the core 100 to the remote microcode and correspondingly reduce the remote microcode access latency.

  In many processor implementations, microcode is often static during the processor implementation and may be implemented, for example, in a read-only control store to minimize the area required by the control store. . However, in some embodiments, it may be useful to provide a technique in which the microcode may be modified, for example, to correct a defect or add functionality. As shown in FIG. 6, in some embodiments, the remote microcode unit 410 may include additional features configured to provide a writable control store.

  The optional microcode patch RAM 660 may be configured to provide a function where specific entry points may be mapped from the microcode ROM bank 650 to the corresponding writable entry 310 in the patch RAM 660. In one embodiment, the patch RAM 660 may include a writable storage resource configured to implement multiple entries 310. In some embodiments, the patch RAM 660 may include the same number of entries 310 as one of the ROM banks 650, but in other embodiments, the number of entries may be increased or decreased. The patch RAM 660 may also provide resources so that each entry 310 corresponds to an assignable entry point. In an embodiment where the remote control store 640 includes multiple ROM banks 650 each having the same number of entries as the patch RAM 660, a given entry 310 of the patch RAM 660 corresponds to any one of the ROM banks 650. It may be mapped to the entry 310. An additional bit set in the patch RAM 660 may specify which bank a given patch RAM entry corresponds to at any given time. For example, an embodiment may include four ROM banks 650 and one patch RAM bank 660, each having 1000 entries. Additional bits in the patch RAM 660 may specify for each given entry 310 which of the four ROM banks a given entry is mapped to. In other embodiments, each entry in the patch RAM 660 may have a corresponding entry point that is programmable.

  To route a given entry 310 within a bank 650, in one embodiment, which bank 650 is shipped or which indicates a particular entry point value associated with a patch RAM entry. With that information, the desired dispatched value for a given entry may be stored in the corresponding entry in patch RAM 660. Subsequently, when a request to access a particular entry point is received by the remote control store 640, the patch RAM 660 may be examined to determine if the requested entry point has been dispatched. For example, the remote control store 640 determines a particular bank 650 that a particular entry point maps to, and then examines the control bit of the corresponding entry 310 in the patch RAM 660 to determine the entry 310 stored in the patch RAM 660. May be configured to be selected instead of the entry 310 stored in a particular bank 650. Alternatively, a particular entry point may be compared to programmed entry points in the patch RAM 660 in an associative manner to determine whether the particular entry point hits or matches an entry in the patch RAM 660. . Although an optional feature of the remote microcode unit 410 is shown as a patch RAM 660, in some embodiments, the local microcode unit 400 can also be a patch RAM in the control store 500 in a manner similar to that described above. Note that features may be supported.

  Patch RAM 660 may easily provide patching of individual microcode entry points. However, in some embodiments, it may be desirable to rewrite an entire routine that includes many entry points or augment existing microcode with new routines. Accordingly, in one embodiment, the remote microcode unit 410 may include an optional dynamic microcode RAM array 670. Generally speaking, the microcode RAM array 670 may be implemented according to any suitable writable or non-volatile storage array technology, in addition to those stored in the remote control store 640 and the local control store 500. Thus, a large number of entries 310 may be stored. In one embodiment, the portion of the microcode address space associated with entry 310 of microcode RAM array 670 is derived from the portion of the microcode address space associated with entry 310 in remote control store 640 and local control store 500. The microcode access request received by the remote microcode unit 410 may be separate and directed to either the remote control store 640 or the microcode RAM array 670 according to the requested entry point. May be.

  In other embodiments, an entry 310 in the microcode RAM array 670 may be configured to shadow or override entry points that also map to the remote control store 640. For example, microcode RAM array 670 may include programmable entry point control bits or registers similar to those described above for patch RAM 660. In such an embodiment, a particular entry point that maps to the remote microcode unit 410 may be checked to see if the corresponding entry 310 has been defined in the microcode RAM array 670. If so, any corresponding entry 310 in the remote control store 640 may be ignored. In some embodiments of the remote microcode unit 410 that support some degree of sequencing, once an entry point is mapped to the microcode RAM array 670, eg, at the beginning of a multi-entry microcode routine, Consecutive references may remain within a portion of the microcode address space allocated to the microcode RAM array 670. This may allow the remainder of the routine to execute from the RAM array 670 without further reference to the remote control store 640.

  Although the above embodiments have been described with reference to a two-level hierarchy that includes a local microcode unit 400 and a remote microcode unit 410, in other embodiments, the microcode can be used in the processor 200 using additional levels of hierarchy, Note that it may also be distributed across multiple instances of processor 200 in the system.

  In some embodiments, the processor 200 may be implemented in a computer system along with other components. FIG. 8 illustrates one embodiment of such a system. In the illustrated embodiment, computer system 800 includes a number of processing nodes 812A, 812B, 812C, and 812D. Each processing node is connected to each of the memories 814A to 814D via memory controllers 816A to 816D included in each of the processing nodes 812A to 812D. Further, processing nodes 812A-812D include interface logic used to communicate between processing nodes 812A-812D. For example, interface logic A for communicating with processing node 812Aha, processing node 812B, interface logic 818B for communicating with processing node 812C, and a third for communicating with yet another processing node (not shown). Interface logic 818C. Similarly, processing node 812B includes interface logic 818D, 818E, and 818F, processing node 812C includes interface logic 818G, 818H, and 818I, and processing node 812D includes interface logic 818J, 818K, and 818L. Including. Processing node 812D is coupled to communicate with a plurality of input / output devices (eg, devices 820A-820B in a daisy chain configuration) via interface logic 818L. Other processing nodes may communicate with other I / O devices in a similar manner.

  Processing nodes 812A-812D may be configured to implement a packet-based link for node communication between processes. In the illustrated embodiment, the links are implemented as a set of unidirectional lines (eg, line 824A is used to transmit packets from processing node 812A to processing node 812B, and line 824B is transmitted from processing node 812B. Used to send packets to processing node 812A). Another set of lines 824C-824H is used to transmit packets between other processing nodes, as shown in FIG. In general, each set of lines 824 may include one or more data lines, one or more clock lines corresponding to the data lines, and one or more control lines indicating the type of packet being carried. The link may be operated in a cache coherent manner for communicating between processing nodes or in a non-coherent manner for communicating between a processing node and an I / O device (or Peripheral Component Interconnect (PCI)). Interconnect) bus or conventional structure bus bridge and I / O bus, such as an Industry Standard Architecture (ISA) bus. Further, the links may be operated incoherently using a daisy chain structure between I / O devices as shown. Note that a packet sent from one processing node to another may pass through one or more intermediate nodes. For example, a packet transmitted from the processing node 812A by the processing node 812D may pass through either the processing node 812B or the processing node 812C as shown in FIG. Any suitable routing algorithm may be used. Other embodiments of the computer system 800 may include more or fewer processing nodes than the embodiment shown in FIG. Also, other embodiments of the computer system 800 may be implemented using a bidirectional bus that employs an appropriate interface protocol rather than a unidirectional bus that employs a packet-based protocol as described above.

  In general, a packet may be sent on line 824 between nodes as one or more bit times. The bit time may be the rising or falling edge of the clock signal on the corresponding clock line. The packets may include command packets for initiating transactions, probe packets for maintaining cache coherency, and response packets from responses to probes and commands.

In addition to the memory controller and interface logic, the processing nodes 812A-812D may include one or more processors. Broadly speaking, the processing node comprises at least one processor and may optionally include a memory controller for communicating with memory and other logic as required. More specifically, each processing node 812A-812D may comprise one or more copies of the processor 200 as shown in FIG. 2 (eg, various structures shown in FIGS. 1 and 3-7). And details of operations). One or more processors may be chip multiprocessing (CMP) or chip multithread (CMT) in forming a processing node or processing node.
multithreaded) integrated circuit, or the processing node may have any other desired internal structure. In some embodiments, the memory controller and / or peripheral interface logic of the processing node 812 may be integrated directly into the processor 200, as shown in FIG. For example, an instance of the memory controller 816 may correspond to the memory controller / peripheral interface 230 in the processor 200.

  Memories 814A-814D may comprise any suitable memory device. For example, the memories 814A-814D may include one or more RAMBUS DRAM (RDRAM), synchronous DRAM (SDRAM), DDR SDRAM, static RAM, and the like. The address space of computer system 800 may be divided among memories 814A-814D. Each processing node 812A-812D determines which address is mapped to which memory 814A-814D and thus to which processing node 812A-812 the memory request for a particular address should be routed. It may also include a memory map used to determine. In one embodiment, the coherency point of the address in computer system 800 is a memory controller 816A-816D coupled to a memory that stores a byte corresponding to the address. In other words, the memory controllers 816A to 816D may be responsible for causing each memory access to the corresponding memories 814A to 814D to occur in a cache coherent manner. The memory controllers 816A to 816D may include a control circuit for providing an interface to the memories 814A to 814D. Further, the memory controllers 816A-816D may include a request queue for queuing memory requests.

  In general, interface logic 818A-818L may include various buffers for receiving packets from the link and buffering packets transmitted over the link. As described above, in some embodiments, interface logic 818 may be integrated within processor 200, eg, within memory controller / peripheral interface 230, or within a separate interface separate from the integrated memory controller. . Computer system 800 may employ any suitable flow control mechanism for transmitting packets. For example, in one embodiment, each interface logic 818 stores a number by type of buffer in the receiver at the other end of the link to which the interface logic is connected. The interface logic does not transmit a packet unless the receiving interface logic has a free buffer to store the packet. When the receiving buffer is freed by routing the packet forward, the receiving side interface logic sends a message indicating that the buffer is free to the sending side interface logic. Such a mechanism is sometimes referred to as a “coupon-based” system.

  I / O devices 820A-820B may be any suitable I / O device. For example, I / O devices 820A-820B include a device (eg, a network interface card or modem) for communicating with another computer system to which the device may be coupled. In addition, the I / O devices 820A-820B provide various data acquisition such as video accelerators, audio cards, hard or floppy disk drives or drive controllers, small computer systems interface (SCSI) adapters, and telephone cards, sound cards, and GPIB. Cards or fieldbus interface cards may be included. Further, any I / O device implemented as a card may also be implemented as a circuit with software running on the main circuit board of system 800, within processor 200, and / or at a processing node. It should be noted that the term “I / O device” and the term “peripheral device” are used interchangeably herein.

  Further, one or more processors 200 may be implemented in a conventional personal computer (PC) structure that includes one or more I / O interconnects and / or one or more interfaces of the processor to a bridge to memory. Good. For example, the processor 200 may be configured to be implemented in a North Bridge / South Bridge hierarchy. In such embodiments, the north bridge (which may be coupled to or integrated with the processor 200) provides a high bandwidth connection to system memory, graphics device interfaces, and / or other system devices. While the south bridge may be configured, the low bandwidth to other peripherals via various types of peripheral buses (eg Universal Serial Bus (USB), PCI, ISA, etc.) A connection may be given.

  Although embodiments have been described in great detail above, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. The appended claims are intended to be construed to include all such variations and modifications.

  The present invention may be generally applicable to the field of microprocessors.

Claims (9)

A plurality of processor cores (100) each configured to independently execute instructions defined in accordance with a Programmable Instruction Set Architecture (ISA);
A remote microcode store (640) that is accessible by each of the processor cores (100) and configured to store microcode entries, and a given processor core separates another microcode entry (310). Configured to evaluate the sequence control field (330) of the retrieved entry (310) to determine whether to retrieve the another microcode entry for the given processor core without requesting A processor (200) comprising: a remote microcode unit (410) including a programmed sequencer;
Each of the plurality of processor cores (100) includes a local microcode unit (400) configured to store a microcode entry;
Wherein each of the local microcode unit (400) corresponding to Luma Lee black code routine in the microcode entry stored in the respect meet the performance sensitivity threshold requirements, the remote microcode unit (410) in Each of at least some of the microcode routines corresponding to the microcode entry stored in the table does not meet the performance sensitivity threshold requirement;
Any given core of the processor core (100) is
Generating a given microcode entry point corresponding to a particular microcode entry containing one or more operations to be performed by the given processor core (100);
Determining whether the particular microcode entry is stored in the respective local microcode unit (400) of the given processor core (100);
In response to a determination that the specific microcode entry is not stored in the respective local microcode unit (400), conveys the request for the specific microcode entry to the remote microcode unit (410) A processor further configured to.   In order to determine whether the particular microcode entry is stored in the respective local microcode unit of the given processor core, the given processor core may have the given microcode entry point 2. The processor of claim 1, further comprising:   Each of the processor cores further includes a respective instruction cache configured to store instructions among the instructions, and in response to receiving the particular microcode entry after the request, the given The processor of claim 1 or 2, wherein a processor core is further configured to store the particular microcode entry in the respective instruction cache.   4. A processor according to any one of the preceding claims, wherein at least a part of the remote microcode store comprises a writable memory.   5. A processor according to any one of the preceding claims, wherein the performance sensitivity threshold requirement is dependent on the frequency of execution of a microcode routine.   6. A processor according to any one of the preceding claims, wherein the performance sensitivity threshold requirement depends on the latency of microcode routine execution.   One or more of the local microcode units comprises a microcode cache configured to cache an entry retrieved from the remote microcode unit, wherein the particular microcode entry is the given processor core To determine whether the given processor core requests the specific microcode entry from the remote microcode unit before determining whether it is stored in the respective local microcode unit. 7. A processor according to any one of the preceding claims, configured to determine whether a code entry is in the microcode cache. System memory,
A system comprising: a processor according to claim 1, wherein the processor is coupled to the system memory. In response to the determination that a given microcode routine meets the performance sensitivity threshold requirement, the given microcode routine includes the given microcode routine in each local microcode unit (400) included in the plurality of processor cores (100). Store one or more microcode entries corresponding to microcode routines;
In response to a determination that a given microcode routine does not meet performance sensitivity threshold requirements, the given microcode routine is in a remote microcode unit (410) external to the plurality of processor cores (100). Store one or more microcode entries corresponding to microcode routines;
A given microcode entry point corresponding to a particular microcode entry in which a given core of the plurality of processor cores (100) includes one or more operations performed by the given processor core (100) Each of the plurality of processor cores (100) is configured to independently execute instructions defined in accordance with a Programmable Instruction Set Architecture (ISA) to store microcode entries. Each includes a configured local microcode unit (400),
The given processor core (100) determines whether the particular microcode entry is stored in the respective local microcode unit (400) of the given processor core (100);
In response to a determination that the particular microcode entry is not stored in the respective local microcode unit (400), the given processor core (100) makes a request for the particular microcode entry. A remote microcode store that is configured to store a microcode entry that is transported to a remote microcode unit (410), wherein the remote microcode unit (410) is accessible by each of the processor cores (100) (640) and to determine whether the given processor core should fetch the other microcode entry for the given processor core without requesting another microcode entry (310) separately. To the entry (310) And a sequencer configured to evaluate the cans control field (330), method.

Images