JP7052170B2 - Processor and system - Google Patents

Description

The plurality of embodiments relates to a plurality of processors. In particular, the plurality of embodiments relates to a plurality of processors having a plurality of cores.

FIG. 1 is a block diagram of a prior art processor 100. The processor has a plurality of cores 101. In particular, the illustrated processor has core 0 101-0, core 1 101-1 to core M 101-M. As an example, there may be 2, 4, 7, 10, 16 or any other suitable number of cores. Each of the plurality of cores includes a corresponding single instruction, multiple data (SIMD) execution logic 102. In particular, core 0 includes SIMD execution logic 102-0, core 1 contains SIMD execution logic 102-1, and core M includes SIMD execution logic 102-M. That is, the SIMD execution logic is duplicated for each core. Each SIMD execution logic can operate to handle SIMD, vector or packed data operands. Each of the operands has smaller data elements, such as 8-bit, 16-bit, 32-bit, or 64-bit data elements, packed within the operands and processed in parallel by the SIMD execution logic. You may.

On some processors, each SIMD execution logic may represent a relatively large amount of logic. For example, this may be the case where each SIMD execution logic handles a plurality of wide SIMD operands. Some processors have relatively wide vector or packed data operands, such as 128-bit multiple operands, 256-bit multiple operands, 512-bit multiple operands, 1024-bit multiple operands, and so on. Can be processed. In general, the SIMD execution logic required to handle such a wide range of operands tends to be relatively large and consumes a relatively large amount of die area, which increases the manufacturing cost of the processor and is compared in use. It consumes a large amount of power. Duplicating relatively large SIMD execution logic for each core tends to exacerbate these problems. Moreover, in many applications or operating load scenarios, the SIMD execution logic replicated per core tends to be underutilized, at least for some time. As the number of cores continues to grow in the future, these multiple problems may become even more serious.

Further, in the prior art processor of FIG. 1, each of the plurality of cores also has conventional flow control logic. In particular, core 0 has flow control logic 103-0, core 1 has flow control logic 103-1 and core M has flow control logic 103-M. In general, flow control logic may be designed or optimized to cover a wide range of usage models, such as the introduction of speculative execution. However, this generally tends to be associated with relatively high power consumption, although the benefits tend to be relatively small for SIMD and various other high-throughput operations.

The present invention can be best understood by reference to the following description and a plurality of accompanying drawings used to illustrate the plurality of embodiments of the invention. The plurality of drawings are as follows.

It is a block diagram of a processor by the prior art.

It is a block diagram of the embodiment of the system which has the embodiment of a processor and the embodiment of a memory.

FIG. 6 is a block diagram of an embodiment of a processor having a core 0 including an embodiment of a shared core extended interface logic and an embodiment of a shared core extended logic including an embodiment of the core interface logic.

It is a block flow diagram of the embodiment of the method of processing the embodiment of a shared core extended call instruction.

It is a block diagram of the example of the embodiment of a shared core extended command register.

It is a block flow diagram of the embodiment of the method of processing the embodiment of a shared core extended read instruction.

It is a block flow diagram of the embodiment of the method of processing the embodiment of the supply core expansion stop instruction.

It is a block diagram which shows both the exemplary in-order pipeline and the exemplary register renaming, out-of-order issuance / execution pipeline according to the plurality of embodiments of the present invention.

It is a block diagram which shows both the exemplary embodiment of the in-order architecture core to be included in the processor according to the plurality of embodiments of the present invention, and the exemplary register renaming, out-of-order issuance / execution architecture core.

It is a block diagram of a single processor core according to a plurality of embodiments of the present invention, and is shown together with its connection to an on-die interconnect network and a local subset of its secondary (L2) cache 904.

9 is an enlarged view of a part of the processor core of FIG. 9A according to a plurality of embodiments of the present invention.

FIG. 3 is a block diagram of a processor according to a plurality of embodiments of the present invention, which may have more than one core, may have an integrated memory controller, and may have a centralized image display.

The block diagram of the system which concerns on one Embodiment of this invention is shown.

A block diagram of a first, more specific, exemplary system according to an embodiment of the invention is shown.

A block diagram of a second, more specific, exemplary system according to an embodiment of the invention is shown.

The block diagram of SoC which concerns on embodiment of this invention is shown.

It is a block diagram comparing the use of the software instruction converter which concerns on the plurality of embodiments of the present invention for converting a plurality of binary instructions of a source instruction set into a plurality of binary instructions of a target instruction set.

A plurality of embodiments of a plurality of processors having shared core extension logic shared by a plurality of cores and shared by the plurality of cores (eg, capable of operating to perform data processing for each of the plurality of cores). Disclosed in the specification. Multiple shared core extended usage instructions, multiple processors executing multiple shared core extended usage instructions, multiple methods executed by multiple processors when processing or executing multiple shared core extended usage instructions, and multiple methods. Multiple systems incorporating one or more processors for processing or executing shared core extended use instructions are also disclosed herein.

In the following description, multiple details of a particular microarchitecture, multiple formats of a particular command register, multiple functionality of a particular shared core extended instruction, multiple groups of specific shared core extended instruction, A number of specific details are presented, such as multiple system components of a particular type and interrelationship, and multiple details of a particular logic partitioning / integration. However, it is understood that the embodiments of the present invention may be practiced without these specific details. In the other examples, well-known circuits, structures and techniques are not shown in detail so as not to interfere with the understanding of this description.

FIG. 2 is a block diagram of an embodiment of a system 209 having an embodiment of a processor 210 and an embodiment of a memory 218. Processors and memory are concatenated or communicate with each other via one or more buses or other interconnects 219. In various embodiments, the system 209 may represent a desktop computer system, a laptop computer system, a server computer system, a network element, a mobile phone or another type of electronic device having a multi-core processor and memory.

The processor 210 has a plurality of cores 211. The illustrated processor has cores 0 211-0 to core M 211-M. As an example, 2, 4, 7, 10, 16, 16, 32, 64, 128 or more cores or any other reasonable and appropriate number of cores desirable for a particular implementation. There may be. In some embodiments, each of the plurality of cores may be capable of operating substantially independently of the other plurality of cores. Each of the plurality of cores can process at least one thread. As shown, core 0 has thread 0 212-0 and may optionally include threads P 212-P. Similarly, the core M has threads 0 212-0 and may optionally include threads P 212-P. The number of the plurality of threads P may be any reasonable and appropriate number of threads. The scope of the invention is not limited to any known number of cores, or any known number of threads that can be processed by such multiple cores.

The processors are multiple processors of various complex instruction set computers (CISC), multiple processors of various reduced instruction set computers (RISC), multiple processors of various very long instruction words (VLIW), and various multiple of these. It can be either a hybrid of, or completely other multiple types of multiple processors. In some embodiments, the plurality of cores may be multiple general purpose cores of the type of general purpose processor used in desktops, laptops, servers and similar multiple computer systems. In some embodiments, the plurality of cores may be a plurality of special purpose cores. Multiple examples of suitable special purpose cores include, but are not limited to, multiple graphics processor cores, multiple digital signal processor (DSP) cores, and multiple network processor cores, to name a few. In some embodiments, the processor is a system-on-chip having multiple general purpose or special purpose cores and one or more of the graphics units, media blocks, and one or more of the system memory integrated on the chip with the cores. It may be (SoC).

The processor further includes embodiments of the shared core expansion logic 214. The shared core extension logic is shared by each of the plurality of cores 211 (eg, can act to perform data processing on each of the plurality of cores). The shared core extension logic includes shared data processing logic 216 that can operate to perform data processing on each of the plurality of cores. The shared core expansion logic and the plurality of cores are connected to each other by one or more buses of the processor or a plurality of other interconnects 217. The plurality of cores and shared core extension logics include the corresponding interface logics 213 and 215 so that one or more physical threads and shared core extension logics in each of the plurality of cores interface or cooperate with each other (eg,). , Call shared core extension logic for multiple threads on multiple cores to perform data processing, check the status of data processing, stop data processing, multiple virtual memory attributes for multiple context switches It can be synchronized, route multiple page faults that occur during data processing, etc.). Multiple computer tasks performed by shared core extension logic may be performed under the logical process of that particular physical thread instead of each physical thread. As will be further described later, the context used for the interface may be provided for each physical thread.

In particular, core 0 includes an embodiment of shared core extended interface logic 213-0 that includes at least some logic specific to thread 0 of core 0 and at least some logic specific to thread P of core 0. Similarly, core M includes embodiments of shared core extended interface logic 213-M that includes at least some logic specific to thread 0 of core M and at least some logic specific to thread P of core M. Each of the other cores (if any) also contains such shared core extension interface logic. The shared core extension logic 214 includes an embodiment of the corresponding core interface logic 215. Each core 211 may interface with or cooperate with the core interface logic 215 of the shared core expansion logic 214 via its corresponding shared core expansion interface logic 213. In some embodiments, the shared core expansion interface logic 213 and the core interface logic 215 allow a plurality of cores to share a shared core expansion logic (eg, share data processing by a shared data processing logic 216). Architectural interfaces (eg, new architecture macro instructions and new architecture registers), microarchitecture interfaces or hardware mechanisms (eg, data processing scheduling logic, memory management unit (MMU) synchronization logic, page fault routing). Logic etc.) may be provided. A plurality of detailed exemplary embodiments of the shared core extended interface logic 213 and the core interface logic 215 will be further described below.

The shared data processing logic 216 may represent a plurality of different types of data processing logic in a variety of different embodiments. As mentioned earlier in the background art section, certain types of data processing logic (eg, certain multiple wide SIMD execution units) have traditionally been replicated on a core-by-core basis. As mentioned earlier, this duplicated logic often tends to be relatively large. Moreover, often this duplicated logic is underutilized in many common workload scenarios, at least for some time. Duplication of such logic generally tends to consume a relatively large amount of die area, thus increasing manufacturing costs and consuming a relatively large amount of power. In some embodiments, such relatively large and / or underutilized data processing logic that is traditionally replicated per core is from multiple cores as a single shared copy of the data processing logic. It may be extracted into the shared core extension logic. Moreover, as in the case of the traditional flow control logic of multiple cores in Figure 1, it is designed or optimized to cover a wide range of multiple utilization models, eg, speculative execution deployments. , Shared core expansion logic 214 may employ flow control logic optimized for desired or high throughput. This generally tends to provide a higher level of power performance efficiency for throughput-oriented algorithms.

In various embodiments, the shared data processing logic includes throughput-oriented hardware compute logic, high throughput compute engine, matrix multiplication logic, matrix translocation logic, finite filter logic, total absolute difference logic, histogram computation logic, gathers. It may represent a scatter instruction implementation logic, a transcendental vector execution logic, and the like. In some embodiments, the shared data processing logic may include multiple execution units, such as, for example, multiple SIMD execution units (eg, potentially relatively wide multiple SIMD execution units). In some embodiments, the shared core expansion logic may work with, for example, a plurality of shared core expansion data structures 208 (eg, a plurality of matrices, a plurality of tables, etc.) in memory 218.

Advantageously, compared to logic duplication, shared core extension logic helps reduce one or more of the entire die area required for logic execution, logic manufacturing costs and / or logic power consumption. Can be. That is, according to the shared core extension logic, multiple cores combine multiple resources of common data processing capability evaluation hardware without generally incurring high integration costs to replicate such multiple resources on a core-by-core basis. Can be shared. For clarity, a particular shared data processing logic is not required to be large, but maximizing the benefits of size, cost and power savings is multiple instead of relatively large logic being replicated per core. Often realized when shared by the core of. In addition, shared logic is underutilized, as shared logic can tend to increase logic utilization if it is replicated on a core-by-core basis, otherwise it is relatively underutilized. Alternatively, the integration of unnecessary logic can reduce the die area and manufacturing cost, so that the profit is often maximized. As a further advantage, the shared core expansion logic is potentially a shared core with multiple cores customized or optimized for one type of processing (eg, for scalar operating load performance, power and area). Extended logic may be further used to customize or optimize for other types of processing (eg, for throughput-oriented operating load performance, power and area).

FIG. 3 shows an embodiment of a processor 310 having a core 0 311-0 including an example of an embodiment of a shared core expansion interface logic 313 and an embodiment of a shared core expansion logic 314 including an example of an embodiment of a core interface logic 315. It is a block diagram of a form. As mentioned above, the processor may further include one or more other cores up to core M (not shown). In addition to the shared core extended interface logic 313, core 0 is the type of conventional logic 334 traditionally found in multiple cores (eg, one or more execution units, multiple architecture registers, one or more caches). , Microarchitecture logic, etc.). The scope of the invention is not limited to any known such conventional logic. In addition to the core interface logic 315, the shared core extension logic 314 further includes a shared data processing logic 316 and a scheduler 344 that schedules data processing from a plurality of cores or tasks to the shared data processing logic.

Each of the one or more physical threads running on core 0 311-0 may use shared core extension interface logic 313 to interface with shared core extension logic 314. The shared core extended interface logic 313 includes a plurality of shared core extended use instructions 323 of the instruction set 322 of core 0. The instruction set is part of the core instruction set architecture (ISA). ISA represents part of the core architecture for programming. The ISA generally includes multiple native instructions of the processor, multiple architecture registers, multiple data types, multiple addressing modes, memory architecture, interrupt and exception handling, and the like. ISA is generally distinguished from microarchitectures that represent specific design techniques selected to implement ISA. Multiple processors or multiple cores with different microarchitectures may share a common ISA. Multiple instructions in an instruction set, including a shared core extended instruction 323, are multiple microinstructions, microops, or lower level instructions (eg, decoding logic decoding multiple machine instructions or multiple macro instructions. In contrast to the resulting), it represents multiple machine instructions, multiple macro instructions, or higher level instructions (eg, instructions given to the core for execution).

The shared core extension interface logic 313 further includes a set of core 0s and thread 0s of a plurality of shared core extension command registers (SCERCR) 328. Each physical thread may have a set of multiple SCERCR registers associated with it as part of the context to be saved and restored independently of the progress of the other threads. In some embodiments, for core 0, there may be multiple sets of multiple SCERCRs given per thread for each of one or more physical threads running on core 0. For example, in the illustrated embodiment, the plurality of SCERCRs of core 0 and thread 0 may belong to thread 0. Similarly, each physical thread running on core 0 may have a plurality of core 0, thread-specific sets of SCERCRs to interface with the shared core extension logic 314. Alternatively, for core 0, there may be a single set of multiple SCERCRs of core 0. In such cases, at the hardware level, there may be time to share multiple SCERC Rs among multiple physical threads. Contexts may be swapped, saved and restored from multiple SCERCRs in core 0 at multiple context switches.

In the figure, SCERCRN 0 328-0 to SCERCRN 328-N are shown. That is, there are N + 1 registers. The number N + 1 may be any desired number, such as 2, 4, 8, 16, 32, 64, or some other number. The number N + 1 does not have to be a power of 2, but this generally tends to provide efficient register addressing. A given one of these plurality of registers is commonly represented herein as SCECRx, where x may represent any one of the registers SCERCR0 to SCERCRN.

In some embodiments, the plurality of shared core extended command registers may be multiple registers of the architecturally visible core and / or processor ISA. Multiple architecture registers generally represent multiple storage locations for the on-die processor. Multiple architecture registers may be further referred to herein as simply multiple registers. Unless otherwise specified or apparent, the expressions multiple architecture registers and multiple registers are used herein as software-visible multiple registers and / or programmers (eg, software-visible) and / or multiple. Used to refer to multiple registers specified by macro instructions. These multiple registers are other non-architectural or architectural in a given microarchitecture (eg, multiple temporary registers used for multiple instructions, multiple reorder buffers, multiple retirement registers, etc.). Contrast with multiple registers that are not visible.

The shared core extension instruction 323 is used to send, monitor, and stop multiple calls to the shared core extension logic 314 so that data processing can be performed. As an example, multiple shared core extended instruction may be used for parallel programming, as an instruction set (eg, as an extension of the instruction set) to improve the efficiency and / or throughput of the parallel programming operating load. ) May be included. Multiple shared core extended use instructions explicitly set the shared core extended command register (SCECRx) of multiple shared core extended command registers 328 of core 0 (eg, via multiple bits or one or more fields). It may be specified or indicated (eg, implied). Multiple shared core extension registers may provide the processor's architectural hardware interface to the shared core expansion logic.

In the illustrated embodiment, the shared core extended use instruction 323 includes a shared core extended (SCE) call instruction 324 with a format SCE call (SCECRx, multiple parameters). SCECRx indicates one of the plurality of shared core extended command registers 328 of core 0, and the plurality of parameters indicate one or more parameters associated with the call further described below. The plurality of shared core extended use instructions illustrated further include an SCE read instruction 325 with a format SCE read (SCECRx). Another plurality of shared core extended use instructions is the SCE stop instruction 326 with the format SCE stop (SCECRx). Yet a plurality of shared core extended use instructions are SCE wait instructions 327 with format SCE wait (SCECRx). Each of these instructions may include an operation code or opcode (eg, multiple bits or one or more fields) that can operate to identify the instruction and / or operation to be executed. The functionality of each of these exemplary shared core extended use instructions will be further described below.

It will be appreciated that this is just one example of a suitable set of multiple shared core extended usage instructions. For example, in other embodiments, some of the illustrated instructions may be selectively omitted and / or additional instructions selectively to multiple shared core extended use instructions. May be added. In addition, a plurality of other shared core extended use orders and multiple sets thereof are considered and apparent to those of skill in the art and have the benefit of the present disclosure.

One of the plurality of physical threads running on core 0 311-0 may issue one of the shared core extended use instructions 323. The shared core extended use instruction issued by the thread may indicate a plurality of shared core extended command registers 328 of the appropriate core 0. A plurality of shared core extended command registers of appropriate core 0 may correspond to threads (eg, thread 0) and provide context for each thread.

Referring again to FIG. 3, core 0 includes decoding logic 348. The decoding logic may be further referred to as a decoder or decoding unit. Decoding logic receives and decodes higher level machine instructions or multiple macro instructions, one or more lower level microoperations, multiple microcode entry points, multiple microinstructions or more. Multiple low-level instructions, or multiple control signals derived from and / or derived from the original higher-level instruction, may be output. Multiple lower-level control signals, one or more, implement higher-level instructional operations via one or more lower-level (eg, circuit-level or hardware-level) operations. You may. Decoders are used to perform, but are not limited to, multiple microcode read-only memories (ROMs), multiple look-up tables, multiple hardware implementations, multiple programmable logic arrays (PLAs), and instruction decoding. It may be implemented using a variety of different mechanisms, including a plurality of other mechanisms known in the art used. Further, in some embodiments, an instruction emulator, translator, morpher, interpreter or other instruction conversion logic may be used in place of and / or in addition to the decoding logic.

The SCE instruction execution logic 330 is concatenated with the decoding logic 348 and the plurality of shared core extension command registers 328 of the core 0. Shared core extended instruction execution logic reflects or is derived from one or more microoperations, multiple microcode entry points, multiple microinstructions, multiple other instructions, or multiple shared core extended instruction usage instructions. Other plurality of control signals may be received from the decoder. The shared core extension instruction execution logic performs multiple actions in response to and / or as specified to it (eg, in response to multiple control signals from the decoder). It is possible to operate as if. In some embodiments, the shared core extended instruction execution logic and / or processor executes and / or processes a plurality of shared core extended instruction and responds to and / or responds to the plurality of shared core extended instruction. It may include specific or specific logic (eg, circuits or software and / or other hardware potentially combined with firmware) that can operate to perform multiple operations as specified.

In the illustrated embodiment, the shared core extension instruction execution logic is contained within the shared core extension control logic 329. The shared core expansion control logic is concatenated with a plurality of shared core expansion command registers 328, a decoding logic 348, and a memory management unit 331 further described later. The shared core extended control logic may support various control, management, coordination, timing and related implementation embodiments of the shared core extended interface logic 313.

As mentioned above, the core 0 instruction set includes the SCE call instruction 324. The SCE call instruction may be used to send a call to the shared core extension logic 314 to perform data processing on behalf of the core (eg, instead of running a thread on the core). As an example, a physical or logical thread running on core 0 may issue an SCE call instruction to call or send a command to the shared core extension logic so that data processing is performed. In some embodiments, the call or command may be passed to the shared core extension logic via one or more of the plurality of shared core extended command registers 328. For example, the shared core extended call instruction of the embodiment may specify or indicate one of a plurality of shared core extended command registers 328 (eg, SCECRx) of core 0. That is, the plurality of shared core extended command registers may be accessible by threads on the plurality of cores using the new SCE call macroinstruction. In some embodiments, the SCE call instruction may further specify or indicate one of more parameters in order to further specify, authorize, or define the data processing to be performed. Data may be written or stored in the indicated shared core extended command register (eg, SCECRx) based on the SCE call instruction (eg, based on one or more parameters of the SCE call instruction). If the current SCE call is made to a shared core extended command register that is already dedicated to or occupied by a previous SCE call, the current SCE call is released by the occupied shared core extended command register. May be blocked (eg, when the associated call completes or is stopped). The shared core extension logic may then access the indicated shared core extension command register (eg, SCECRx) containing the written or stored data (eg, perform the requested data processing). ) Calls or commands may be implemented.

FIG. 4 is a block flow diagram of an embodiment of the method 450 for processing an embodiment of an SCE call instruction. In multiple embodiments, the method may be performed by a processor, core or other type of instruction processing device. In some embodiments, method 450 may be performed by processor 210 in FIG. 2 or core 0 311-0 in FIG. 3, or a similar processor or core. Alternatively, method 450 may be performed by a completely different processor, core or instruction processor. Further, the processor 210 and the core 310-1 may perform the same, similar or different, multiple operations and multiple embodiments of the method 450.

At block 451 the SCE call instruction is received within the core of a processor having a plurality of cores. In various aspects, the SCE call instruction may be received in the core from an off-core source (eg, from main memory, disk, or bus or interconnect), or other logic within the core (eg, instruction). It may be received from a part of the core (eg, in the decoding logic, scheduling logic, etc.) from the cache, queue, scheduling logic, etc.). The SCE call instruction causes the core to call the shared core extension logic in order to execute data processing. Shared core extension logic is shared by multiple cores. The SCE call instruction indicates a shared core extended command register and further indicates one or more parameters. One or more parameters specify the data processing to be performed by the shared core extension logic.

In some embodiments, one or more parameters are one or more pointers (eg, multiple explicit virtual memory pointers), command attributes in memory with multiple command attributes associated with the call. One or more pointers to the data structure (eg, one or more explicit virtual memory pointers) to one or more input data operands in the memory in which the data processing should be performed. Pointers (eg, one or more explicit virtual memory pointers) may be provided for one or more output data operands in memory where multiple results of data processing should be stored. For example, in some embodiments, the one or more parameters should further be stored in the plurality of fields of FIG. 5, which will be described below, and / or provide information to be used to extract them. May be good. Alternatively, in other embodiments, one or more fields may have multiple opcodes and direct encoding of multiple arguments instead of multiple memory pointers.

At block 452, the shared core extension logic is called in response to an SCE call instruction so that data processing is performed. In some embodiments, the call to the shared core extension logic may include writing or storing data in the shared core extension command register indicated by the instruction, based on one or more parameters indicated by the instruction. ..

FIG. 5 is a block diagram of an example of an embodiment of the shared core expansion command register 528. The shared core extended command register has a large number of fields. In the illustrated embodiment, from left to right, these plurality of fields include a status field 555, a progress field 554, a command pointer field 555, an input data operand pointer field 556, and an output data operand pointer field 557. .. Each of these plurality of fields may contain a sufficient number of bits to convey the desired information for a particular implementation.

The status field 553 may be used to provide the status of the call corresponding to the shared core extended command register. A plurality of examples of such status include, but are not limited to, call is valid (eg, in progress), call complete, call error, and the like. As an example, the two bits may be used to specify any of the three status conditions described above. In another example, a single bit may be used to encode one of two status conditions, such as valid and invalid. Valid may indicate that the call is currently in progress. Invalid may indicate that an error has occurred.

The progress field 554 may be used to provide the progress of the call corresponding to the shared core extended command register. Progress may represent the level of completion progress or the degree to which a call or command has progressed towards completion. The progress field may effectively implement a type of counter that counts the amount of work completed so far in the execution of the call. In some embodiments, progress may be represented by multiple atomic commit points. For example, the counter may be incremented whenever an atomic suboperation is completed by SCE logic. Atomic sub-operations may vary from one type of data processing to another (eg, in one example, when a cache line of a certain number of data is processed). In some embodiments, the progress field is used to provide the atomicity of progress with respect to the data processing of the shared core extension logic and the ability to preempt and reschedul the execution of commands on the shared core extension logic. May be done. If the call execution is interrupted (eg, at a context switch from one thread to another, or at a fault), the progress field may be saved. The progress field may then be restored and the data processing associated with the call resumed (eg, if the thread resends). Data processing may be resumed where it was interrupted by restoring the progress field. This is especially useful when the amount of data processing to be performed by the SCE logic is relatively large and / or takes a relatively large amount of time to complete.

The command pointer field 555 may be used to provide a pointer to the command attribute information 558 of the call corresponding to the call or shared core extended command register. In some embodiments, the call attribute information may be included in the call attribute data structure. In some embodiments, the call attribute information may be stored in one or more memory locations in memory 518. In some embodiments, the pointer may be an explicit virtual memory pointer. The call attribute information may further specify, authorize, define, or characterize multiple attributes of the call. For example, call attribute information may further specify, authorize, define or characterize the exact type of data processing to be performed by the shared core extension logic. In some embodiments, the plurality of command attributes are relatively simple or short, such as multiple operations that transpose a matrix, multiple operations that generate a histogram, multiple operations that perform filtering, and so on. Processing routines or processing representing a plurality of functions may be described. Multiple command attributes are one or more input data operands (eg, one or more input data) to generate one or more output data operands (eg, one or more output data structures). A sequence of multiple operations to be performed on a structure) may be described. In some embodiments, they may be either various such relatively simple algorithms or typically multiple routines performed by a plurality of hardware accelerators or a plurality of graphics processing units, etc. ..

The input data operand pointer field 556 may be used to provide one or more pointers to one or more input data operands. Multiple input data operands are those whose data processing should be performed by shared core extension logic. In some embodiments, the one or more input data operands may represent one or more data structures such as, for example, a plurality of matrices, a plurality of tables, and the like. As shown, in some embodiments, the pointer may point to an input data operand at the memory location of memory 518. In some embodiments, the pointer may be an explicit virtual memory pointer. In other embodiments, the pointer may point to one or more input data operands at one or more registers or other storage locations.

The output data operand pointer field 557 may be used to provide one or more pointers to one or more output data operands. Multiple output data operands are intended to convey multiple results of data processing performed by the shared core extension logic upon completion of the call. In some embodiments, the one or more output data operands may represent one or more data structures, such as, for example, a plurality of matrices, a plurality of tables, and the like. As shown, in some embodiments, the pointer may point to an output data operand at a memory location in memory. In some embodiments, the pointer may be an explicit virtual memory pointer. In other embodiments, the pointer may point to one or more output data operands at one or more registers or other storage locations.

It will be appreciated that this is just one example of a format suitable for shared core extended command registers. In another embodiment, some of the illustrated fields may be omitted, or additional fields may be added. For example, one or more of the fields may be provided via an implied position that does not need to be explicitly specified in the shared core extended command register. As another example, the input data operand storage position may be reused as the output data operand storage position so that it does not need to be specified twice, but one of the specifications is implicit. May be good. As yet another example, one or more fields may have multiple opcodes and direct encoding of multiple arguments instead of multiple memory pointers. Moreover, the illustrated order / configuration of the fields is not required, rather the fields may be reconstructed. Further, the field does not have to contain a continuous sequence of bits (as suggested in the figure), but rather may consist of discontinuous or separated bits.

Referring again to FIG. 3, after the execution of the SCE call instruction, the shared core extended command register indicated by the SCE call instruction (eg, SCECRx) may store the data corresponding to the SCE call instruction. After a thread or core sends a task or call, the thread or core prepares and shares additional calls or tasks before the previously sent multiple calls or tasks complete. You may proceed to send to. In addition, the thread or core may proceed to perform other processing while the previously transmitted calls or tasks are completed. Multiple shared core extension command registers, along with the scheduler (discussed further below), include multiple threads and / or multiple threads and / or multiple until the completion of multiple tasks or calls to the shared core extension logic, and until these are completed. May help provide a fine-grained control flow that allows the core to send multiple tasks or calls and then proceed to send other tasks or calls or perform other processing. ..

The shared core expansion logic 314 includes a core interface logic 315 that accesses a plurality of core 0 shared core expansion command registers 328. Core interface logic may be further used to access multiple shared core extension command registers 340 of core M and any other multiple cores (if any). That is, in some embodiments, the shared core extension logic and / or the core interface logic may access a separate set of multiple shared core extension command registers for each of the plurality of cores.

The shared core extension logic may use a plurality of shared core extension command registers 328. For example, the shared core extension logic may access command attribute information pointed to in a command field (eg, field 555) and may have multiple input data pointed to in a plurality of input data operand fields (eg, field 556). The operands may be accessed, the progress may be updated as a result of data processing in the progress field (eg, field 554), and if an operation is performed or an error is encountered, the completion or error is reflected. The status field (eg, field 553) may be updated to do so, and if completed without error, to multiple output data operands via pointers to multiple output data operand fields (eg, field 557). You may access it.

For ease of explanation, the shared core extension logic is shown as having multiple copies of the shared core extension command registers for core 0, thread 0. However, multiple shared core extension command registers in the shared core extension logic may actually not have two sets of multiple shared core extension command registers for core 0, thread 0, and multiple dashed lines. Indicated by. Rather, both core 0 and shared core extension logic may logically look at the same set of multiple shared core extension command registers for core 0, thread 0. Similarly, the shared core extension logic may potentially look at the corresponding shared core extension command registers of other threads of other processors up to set 340 of core M, thread P. .. For further clarity, multiple shared core extension command registers for physical core 0, thread 0 can be placed in core 0, in shared core extension logic, outside of core 0 and outside of shared core extension logic, or. It may be located in a combination of a plurality of different positions.

The shared core extension logic 314 includes an embodiment of the scheduler 344. The scheduler may be implemented in hardware, software, firmware or some combination. In one aspect, the scheduler may be a hardware scheduler. The scheduler accesses the multiple shared core extension command registers 340 of the core M from the shared core extension command register 328 of the core 0, and makes multiple calls transmitted through these multiple registers on the shared data processing logic 316. It may be operational to schedule the associated data processing. In some embodiments, the scheduler may represent a programmable hardware scheduler or programmable hardware scheduling logic that schedules data processing for multiple cores according to a programmable scheduling algorithm or purpose. In some embodiments, the hardware scheduler may be implemented as a state machine that can operate to circulate between a plurality of commands and between a plurality of physical threads. Multiple arbitration policies may potentially be exposed to software via a set of multiple Machine Specific Registers (MSRs). In other embodiments, the hardware scheduler may be implemented, for example, as a firmware block incorporating both fixed read-only memory (ROM) and patchable random access memory (RAM) domains. This potentially allows the hardware scheduler to combine multiple operating system instructions, multiple application programming interfaces (APIs), multiple runtime compiler instructions, multiple real-time hardware signals or such controls. More complex scheduling algorithms can be used that may depend on it. As an example, scheduling is a fair scheduling algorithm, a scheduling algorithm that is more weighted to some of the cores than others (eg, core load, critical time of thread being processed or data, thread priority). Based on or according to several other purposes). Many different types of scheduling algorithms known in the art are suitable for different implementations for a particular purpose of those implementations. The scheduler may further monitor the completion of multiple scheduled calls or tasks to the shared data processing logic.

The shared core extension logic 314 further includes a status and / or progress update logic 349. The status and / or progress update logic may monitor the status and / or progress of a plurality of calls being processed by the shared data processing logic 316. The status and / or progress update logic may further update multiple shared core extended command registers corresponding to multiple calls based on the monitored status and / or progress. For example, the status field 553 and the progress field 554 in FIG. 5 may be updated. As an example, if the call to the shared core extension logic is completed, the status may be updated to reflect that it was completed, or if the call process to the shared core extension logic faces an error, the status is. It may be updated to reflect the error condition. As another example, across the data processing associated with the call, the status and / or progress update logic may update the progress of the call completion (eg, in the progress field 554, a plurality of atomic commit points. May be updated).

In some embodiments, the operating system also uses state save / restore functionality (eg, xsave / xstore in Intel architecture) to manage the state of shared core extended command registers in multiple context switches. good. Multiple calls or commands that have not yet been completed by the shared core extension logic may be saved by the physical thread in the context switch and then restored and resumed. In some embodiments, to support context switching and operating system preemption, the plurality of shared core extension command registers are the data being processed by the shared core extension logic by having the progress fields described above. Processing tasks (eg, atomic progress) may be recorded. Progress fields are stored in the context switch as part of the thread context and may be used to resume the task if the operating system reschedules the thread.

The shared core extension logic 315 further includes a shared core extension control logic 343.

The shared core expansion control logic includes a scheduler 344, a shared data processing logic 316, a status / progress update logic 349, a plurality of shared core expansion command registers 328 and 340 of cores 0 to M, and a shared core expansion memory management unit described later. (MMU) 341 is connected. The shared core extended control logic may support various implementations involving various controls, management, coordination, timing and shared core extended logic 314.

Referring again to the SCE call instruction 324 of FIG. 3 and / or the SCE call instruction of the method of FIG. 4, in some embodiments, the SCE call instruction may be a non-blocking SCE call instruction. In some embodiments, the non-blocking SCE call instruction may be sent non-speculatively from a thread (eg, a physical thread) and the non-blocking SCE call instruction is accepted for execution in the shared core extension logic. After that, it may be retired at the core where the issuing thread is running (for example, stored in the SCE command register).

In a plurality of other embodiments, the SCE call instruction may be a block SCE call instruction.

In some embodiments, the block SCE call instruction may be sent non-speculatively from a thread (eg, a physical thread) after the call or task execution is completed in the shared core extension logic (eg, eg). If the status field of the shared core extended command register is updated to reflect completion), it may retire on the core running the issuing thread. In some embodiments, both non-blocking and blocking differences of multiple SCE calling instructions may be included in the instruction set.

In some embodiments, the block SCE call instruction may specify or indicate a timeout value (eg, the number of cycles) to wait for the shared core extended command register to be released. For example, this number of cycles or other timeout value may be specified as one of the parameters of the SCE call instruction. In some embodiments, failures, faults, errors, etc. may be returned in response to a call if the timeout value is reached without the shared core extended command register being released.

Upon retirement of the SCE call instruction, the shared core extension logic may modify the memory state according to the assigned task or call. In a multithreading environment, shared core extensions may be used to perform software synchronization to maintain cache coherency and memory order across multiple logical threads that may have multiple shared operands. Alternatively, hardware synchronization may also be performed selectively.

FIG. 6 is a block flow diagram of the embodiment of the method 662 for processing the embodiment of the SCE read instruction. In multiple embodiments, the method may be performed by a processor, core or other type of instruction processing device. In some embodiments, method 662 may be performed by processor 210 in FIG. 2 or core 0 311-0 in FIG. 3, or a similar processor or core. Alternatively, method 662 may be performed by a completely different processor, core or instruction processor. Further, the processor 210 and the core 310-1 may perform the same, similar or different, multiple operations and multiple embodiments of the method 662.

The shared core extension (SCE) read instruction is received in block 663 within the core of a processor having a plurality of cores. In various aspects, the SCE read instruction may be received in the core from an off-core source (eg, from main memory, disk, or bus or interconnect), or other logic within the core (eg, instruction). It may be received from a part of the core (eg, in the decoding logic, scheduling logic, etc.) from the cache, queue, scheduling logic, etc.). The SCE read instruction causes the core to read the status of the previous call to the shared core extension logic. Shared core extension logic is shared by multiple cores. The SCE read instruction indicates a shared core extended command register.

The status of the previous call to the shared core extension logic is read in block 664 in response to the SCE read instruction. In some embodiments, reading the status may include reading data from the shared core extended command register indicated by the instruction. In some embodiments, the status may include a completion status. For example, the status field (eg, status field 553 in FIG. 5) may be read. In some embodiments, the read status may be selected from Complete, Error, Valid, but the scope of the invention is not thus limited.

In a plurality of other embodiments, the SCE read instruction may read other information from the indicated shared core extended command register. A plurality of examples of such information are, but are not limited to, the progress (eg, from the progress field 554 in FIG. 5), the output data operands (eg, as indicated by the field 557) and some of them. Contains command attribute information (eg, as indicated by field 555). In some embodiments, the shared core extended command register corresponds to a previous call to the shared core extended logic so that data processing is performed instead of the core receiving the SCE read instruction.

FIG. 7 is a block flow diagram of the embodiment of the method 766 for processing the embodiment of the SCE stop command. In multiple embodiments, the method may be performed by a processor, core or other type of instruction processing device. In some embodiments, method 766 may be performed by processor 210 in FIG. 2 or core 0 311-0 in FIG. 3, or a similar processor or core. Alternatively, method 766 may be performed by a completely different processor, core or instruction processor. Further, the processor 210 and the core 310-1 may perform the same, similar or different, multiple operations and multiple embodiments of the method 766.

The shared core extension (SCE) stop instruction is received in block 767 within the core of a processor having multiple cores. In various aspects, the SCE stop instruction may be received in the core from an off-core source (eg, from main memory, disk, or bus or interconnect), or other logic within the core (eg, instruction). It may be received from a part of the core (eg, in the decoding logic, scheduling logic, etc.) from the cache, queue, scheduling logic, etc. The SCE stop instruction is for the core to stop the previous call to the shared core extension logic. Shared core extension logic is shared by multiple cores. The SCE stop instruction indicates a shared core extended command register.

At block 768, the previous call to the shared core extension logic is stopped in response to the SCE stop instruction. In some embodiments, stopping the call may include stopping data processing by the shared core extension logic corresponding to the previously made call and / or the indicated shared core extension command register. In some embodiments, stopping the call may further include releasing the occupied shared core extended command register indicated by the SCE stop instruction.

In some embodiments, the block SCE call instruction may specify or indicate a timeout value (eg, the number of cycles) to wait for the SCERC R to be released, and the call may return a fail if the timeout has elapsed. A good fail can occur either if the timeout is reached without release and / or if the timeout is reached while a command execution that has not completed before the timeout elapses. In non-blocking calls, SCE wait instructions may be used to block for shared core extended execution. The SCE wait instruction may also include a timeout value (eg, the number of cycles) for waiting for the release of the shared core extended command register. If the timeout elapses without releasing the shared core extended command register, failures, errors, etc. may be returned. In some embodiments, the timeout values for the block SCE call instruction and / or the SCE wait instruction may be encoded as variable parameters that the instruction can specify. In other embodiments, the timeout may be a fixed, implied value. In some embodiments, the SCE wait instruction may be used with a non-blocking SCE call instruction to reduce power consumption. For example, if a block SCE call instruction blocks and / or an SCE wait instruction blocks, the physical thread is selectively interrupted (assuming no other work is desired to be done) and is associated. May be put to sleep until the shared core extension logic wakes up upon completion of the SCE call. However, this is selective and not necessary. In addition to the above approach of indicating a timeout value via a block SCE call instruction and / or an SCE wait instruction, there are several other ways to stop an unexpected or undesired long-running call or command. , Will be considered.

In some embodiments, the SCE logic may operate on the same virtual memory as core 0. Referring again to FIG. 3, core 0 311-0 has a memory management unit (MMU) 331. The MMU includes a shared core extended MMU interface logic 332. The MMU 331 may be substantially conventional, except for the shared core extended MMU interface logic 332. The shared core extension logic 314 has a shared core extension MMU341. The SCE MMU may maintain the page mapping of core 0 (eg, cache or retain multiple conversions from virtual or linear memory to system memory cached or held by core 0). In addition to maintaining multiple TLB entries corresponding to those of the core 0 TLB, the SCE MMU may further maintain multiple TLB entries for each of the plurality of o-cores. The shared core extension MMU has a core MMU interface logic 342. The shared core extended MMU interface logic 332 and the core MMU interface logic 342 interface with each other to perform synchronization 346 between the MMU 331 and the shared core extended MMU 341. In some embodiments, the shared core extended MMU interface logic 332 and core MMU interface logic 342 may represent a hardware mechanism or hardware support for synchronization of the MMU 331 and shared core extended MMU 341.

In some embodiments, synchronization between the MMU and SCE MMU may be performed to maintain consistency in this page mapping. For example, if the page is invalidated by core 0, core 0 may invalidate the corresponding TLB entry in the core 0 MMU. In some embodiments, synchronization may also be performed between core 0 and SCE logic, where the corresponding TLB entry for the SCE logic's SCE MMU may also be correspondingly invalidated. As an example, a physical thread running on core 0 on a processor uses the hardware interface provided by the shared core extended MMU interface logic 332 and core MMU interface logic 342 to signal the SCE logic. The TLB of the corresponding SCE MMU may be disabled via multiple bus cycles. That is, in some embodiments, synchronization of the shared core extended MMU341 may be performed by hardware from within a physical thread running on core 0. As another example, if a thread is swapped by the operating system (eg, a context switch), the SCE logic will be able to save the context associated with the thread so that it can be restored later with the context switch signals and / Or you may be notified. In some embodiments, such synchronous signaling may be at the hardware level (eg, via multiple bus cycles or multiple bus transactions via hardware mechanisms). That is, synchronization is performed at the hardware level (eg, via MMU and SCE MMU hardware, as well as multiple bus transactions) rather than through software involvement (eg, without operating system involvement). You may.

In some embodiments, the MMU331 and the shared core extension MMU341 are interface logics for routing or communicating for multiple page faults that occur when the shared core extension logic handles multiple calls to core 0. Further cooperation may be made via 332 and 342. In some embodiments, the shared core extended MMU may use core 0 to notify the operating system of page faults that occur while processing a call from core 0. Similarly, the shared core extended MMU may notify these other cores of multiple page faults that occur while processing multiple calls from the other cores. Multiple cores may notify the operating system of multiple page faults. The operating system may have no basis for knowing that the page fault actually occurred in the SCE logic, not in the core that gave the page fault. In some embodiments, the instruction pointer that specifies a fault for the core for the non-blocking SCE call instruction may be arbitrary. In some embodiments, for a block SCE call instruction, the instruction pointer for the faulted shared core extension logic may point to the SCE call instruction corresponding to the faulted call to the calling thread.

Shared core extension logic offers many advantages over other approaches known in the art for offloading processing. Traditionally, a software-based paradigm has been used to work with a plurality of hardware accelerators by a plurality of hardware accelerators (eg, a plurality of graphics processing units) and the like. Multiple hardware accelerators are generally managed by multiple software device drivers. Multiple system calls use multiple applications to use the processing of multiple hardware accelerators. Software (eg, operating system) intervention is often required to provide fair utilization of hardware accelerators by multiple different threads running on multiple cores. Compared to such multiple hardware accelerators, the shared core extension logic uses shared core extension logic (eg, multiple general purpose cores) without shifting to the software paradigm of driver-based hardware accelerator access. The traditional programming paradigm of the core of is possible. Further, in a plurality of embodiments in which the SCE logic operates on the same virtual memory as a plurality of associated physical threads, it can be used without the overhead associated with data copying and / or data marshalling. In addition, compared to hardware accelerators, shared core extension logic generally involves a small amount of open pages to advance progress. In addition, compared to hardware accelerators, shared core extension logic generally tends to reduce latency overhead, which effectively sends commands to the latency of a roughly non-speculative core bus cycle. SCE logic is also hardware or other on-processor to provide fair and distributed use among different threads running on multiple cores, rather than through software (eg, operating system) intervention. You may use the scheduling unit in the logic of.

In the above description, for simplicity of illustration and description, a plurality of embodiments have shown and described a single example of shared core extension logic (eg, Logic 214, Logic 314, etc.). However, in some embodiments, there may be more than one shared core extension logic. Each shared core expansion logic can be either the same multiple cores or different multiple cores, and can be shared by multiple cores that can be all of the multiple cores or some of the multiple cores. good.

In some embodiments, a plurality of different types of shared core extension logic (eg, performing a plurality of different types of data processing) may be included in and shared among the plurality of cores. In other cases, multiple examples of the same generic type of shared core extension logic may be contained in all of the multiple cores (eg, these multiple threads) and may be shared between them, or each. Shared core extension logic may be shared by a subset of the total number of cores (eg, different subsets). Various configurations are considered, as will be appreciated by those skilled in the art and those who have the benefit of the present disclosure.

The plurality of components, the plurality of features and the plurality of specific details described with respect to FIG. 5 may be used together with those of FIGS. 3, 4 or 6. The features and / or details of the device described herein are also selectively applied to the methods described herein by and / or with the device. For example, the plurality of components, the plurality of features, and the plurality of specific details described with respect to FIG. 3 may be selectively used together with those of FIG. 4 or 6.

[Exemplary multiple core architectures, multiple processors and multiple computer architectures]

The plurality of processor cores may be implemented in different embodiments, for different purposes, and in different processors. For example, multiple implementations of such multiple cores are: 1) general purpose in-order core for general-purpose computing, 2) high-performance general-purpose out-of-order core for general-purpose computing, and 3) mainly graphics and / or scientific (throughput) computing. May include special purpose cores for. Multiple implementations of multiple different processors are 1) a CPU containing one or more general purpose in-order cores for general purpose computing and / or one or more general purpose out of order cores for general purpose computing, and 2) main. May include a coprocessor containing one or more special purpose cores for graphics and / or scientific (throughput). With such different processors, 1) a coprocessor on a separate chip from the CPU, 2) a coprocessor on a separate die in the same package as the CPU, and 3) a coprocessor on the same die as the CPU (in this case). Such coprocessors are optionally referred to as special purpose logic, such as centralized image display and / or scientific (throughput) logic, or special purpose core), and 4) the described CPU (possibly application core or Different computer system architectures are configured that may include a system on a chip (referred to as an application processor), the coprocessors described above and additional functionality on the same die. Next, exemplary core architectures will be described, followed by exemplary processors and computer architectures.

[Exemplary multiple core architectures]
[Block Diagram of In-Order and Out-of-Order Core] FIG. 8A shows both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issuance / execution pipeline according to a plurality of embodiments of the present invention. It is a block diagram which shows. FIG. 8B is a block diagram showing both an exemplary embodiment of an in-order architecture core to be included in a processor according to a plurality of embodiments of the present invention, as well as an exemplary register renaming and out-of-order issuance / execution architecture core. Is. Multiple solid boxes in FIGS. 8A-B indicate in-order pipelines and in-order cores, and a plurality of selectively added dashed boxes indicate register renaming, out-of-order issuance / execution pipelines and cores. .. Since the in-order mode is a subset of the out-of-order mode, the out-of-order mode will be described.

In FIG. 8A, processor pipeline 800 includes fetch stage 802, length decode stage 804, decode stage 806, allocation stage 808, rename stage 810, scheduling (also known as dispatch or issue) stage 812, register read / memory read. Includes stage 814, execution stage 816, writeback / memory write stage 818, exception handling stage 822 and commit stage 824.

FIG. 8B shows a processor core 890 including a front-end unit 830 coupled to an execution engine unit 850, both coupled to a memory unit 870. The core 890 may be a reduced instruction set computer (RISC) core, a complex instruction set computer (CISC) core, a very long instruction word (VLIW) core or a hybrid or alternative core type. Yet another option, the core 890 may be a special purpose core such as, for example, a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics score, and the like.

The front-end unit 830 includes a branch prediction unit 832 concatenated to the instruction cache unit 834, the instruction cache unit 834 is concatenated to the instruction translation lookaside buffer (TLB) 836, and the TLB 836 is concatenated to the instruction fetch unit 838. Then, the instruction fetch unit 838 is concatenated to the decoding unit 840. The decoding unit 840 (or decoder) decodes a plurality of instructions and, as output, decodes from one or more microoperations, a microcode entry point, a microinstruction, another instruction or the original multiple instructions. Alternatively, they may be reflected in other ways, or other control signals derived from them may be generated. The decoding unit 840 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROMs), and the like. In one embodiment, the core 890 includes a microcode ROM or other media that stores microcode for a particular plurality of macro instructions (eg, in a decryption unit 840 or in a front-end unit 830). The decryption unit 840 is connected to the rename / allocator unit 852 in the execution engine unit 850.

The execution engine unit 850 includes a retirement unit 854 and a rename / allocator unit 852 coupled to a set of one or more scheduler units 856. The scheduler unit 856 represents an arbitrary number of different schedulers including a plurality of reserved stations, a central command window, and the like. The scheduler unit 856 is concatenated to the physical register file unit 858. Each physical register file unit 858 represents one or more physical register files, where different physical register files are scalar integers, scalar floating point, packed integers, packed floating point, vector integers, vector floating point, status ( Stores one or more different data types, such as an instruction pointer), which is the address of the next instruction to be executed. In one embodiment, the physical register file unit 858 comprises a vector register unit, a write mask register unit, and a scalar register unit. These plurality of register units may provide a plurality of architecture vector registers, a plurality of vector mask registers, and a plurality of general-purpose registers. The physical register file unit 858 can be overlapped with the retirement unit 854 to implement register renaming and out-of-order execution in various ways (eg, using a reorder buffer and a retirement register file). , Using a history buffer and a retirement register file, using a register map and a pool of multiple registers, etc.). The retirement unit 854 and the physical register file unit 858 are concatenated to the execution cluster 860. Execution cluster 860 includes a set of one or more execution units 862 and a set of one or more memory access units 864. Multiple execution units 862 may perform various operations (eg, multiple operations) on multiple different types of data (eg, scalar floating point, packed integer, packed floating point, vector integer, vector floating point). Shift, add, subtract, multiply) may be performed. Some embodiments may include multiple execution units dedicated to a particular function or multiple sets of functions, while other embodiments may include only one execution unit or all. It may include multiple execution units that perform all of the functions of. The scheduler unit 856, the physical register file unit 858 and the execution cluster 860 are sometimes shown as plural, because the particular embodiments may have multiple specific data types / operations (eg, each). Scalar integer pipeline with its own scheduler unit, physical register file unit and / or execution cluster, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline and / or memory access pipeline And, in the case of a separate memory access pipeline, only the execution cluster of this pipeline implements a particular plurality of embodiments having a memory access unit 864). Is. It should also be understood that if multiple separate pipelines are used, one or more of these pipelines may be out-of-order issuance / execution and the rest may be in-order.

The set of memory access units 864 is concatenated to the memory unit 870 including the data TLB unit 872, the data TLB unit 872 is concatenated to the data cache unit 874, and the data cache unit 874 is concatenated to the secondary (L2) cache unit 876. Be concatenated. In one exemplary embodiment, the memory access unit 864 may include a load unit, a store address unit and a store data unit, each of which is concatenated to a data TLB unit 872 within the memory unit 870. The instruction cache unit 834 is further linked to the secondary (L2) cache unit 876 in the memory unit 870. The L2 cache unit 876 is concatenated to one or more other levels of cache and ultimately to main memory.

As an example, an exemplary register renaming, out-of-order issuance / execution core architecture may implement Pipeline 800 as follows: 1) the instruction fetch 838 executes the fetch stage 802 and the length decoding stage 804, 2) the decoding unit 840 executes the decoding stage 806, and 3) the rename / allocator unit 852 performs the allocation stage 808 and the rename stage 810. 4) The scheduler unit 856 executes the scheduling stage 812, 5) the physical register file unit 858 and the memory unit 870 execute the register read / memory read stage 814, and the execution cluster 860 executes the execution stage 816. 6) the memory unit 870 and the physical register file unit 858 perform the writeback / memory write stage 818, 7) various multiple units may be involved in the exception handling stage 822, and 8 ) Retirement unit 854 and physical register file unit 858 execute commit stage 824.

Core 890 is one or more instruction sets containing the instructions described herein (eg, x86 instruction set (with some extensions added to multiple newer versions), Sunnyvale, California). MIPS Technologies' MIPS instruction set, ARM Holdings' ARM instruction set in Sunnyvale, California (with multiple selective further extensions such as NEON) may be supported. In one embodiment, the core 890 includes logic that supports a packed data instruction set extension (eg, AVX1, AVX2) so that multiple operations used by many multimedia applications can be performed with the packed data. To.

It should be understood that the core may support multithreading (performing two or more parallel sets of multiple operations or multiple threads), timed multithreading, simultaneous multithreading (single). The physical core provides a logical core for each of multiple threads so that the physical core performs simultaneous multithreading) or a combination of these (eg, time-split fetching and decoding, then Intel. Multithreading may be performed in a variety of embodiments, including (simultaneous multithreading with Hyper-Threading Technology, etc.).

Register renaming is described in the context of out-of-order execution, but it should be understood that register renaming may be used in in-order architectures. Illustrative embodiments of the processor further include a separate instruction cache unit 834 and a data cache unit 874 with a shared L2 cache unit 876, while alternative embodiments include, for example, a primary (L1) internal cache. Alternatively, it may have a single internal cache for both instructions and data, such as multiple levels of internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache that is external to the core and / or processor. Alternatively, all caches may be outside the core and / or processor.

[Concrete, exemplary in-order core architecture]
9A-B show a block diagram of a more specific, exemplary in-order core architecture, where the core is some logic blocks within the chip (of the same type and / or of several different types). It may be one of (including a plurality of cores of). Multiple logic blocks communicate with some fixed-function logic, memory I / O interfaces and other required I / O logic via high bandwidth interconnect networks (eg, ring networks), depending on the application. conduct.

FIG. 9A is a block diagram of a single processor core according to a plurality of embodiments of the present invention, shown with a connection to the on-die interconnect network 902 and a secondary (L2) cache local subset 904. In one embodiment, the instruction decoder 900 supports an x86 instruction set with a packed data instruction set extension. According to the L1 cache 906, low latency access to the cache memory is possible for the scalar and the vector unit. In one embodiment (for design simplification), the scalar unit 908 and the vector unit 910 use separate register sets (multiple scalar registers 912 and multiple vector registers 914, respectively) and transfer between them. The data to be generated is written to the memory of the primary (L1) cache 906 and then read back, but alternative embodiments of the present invention use different approaches (eg, using a single register set, or). A communication path that transfers data between two register files without writing and rereading) may be used.

The L2 cache local subset 904 is part of a global L2 cache that is divided into one separate local subset per processor core. Each processor core has a direct access path to its own L2 cache local subset 904. The data read into the processor core is stored in its own L2 cache subset 904 and can be quickly accessed in parallel with multiple other processor cores accessing its own multiple local L2 cache subsets. .. The data written to the processor core is stored in its own L2 cache subset 904 and, if necessary, flushed from a plurality of other subsets. The ring network guarantees coherency for shared data. The bidirectional ring network allows multiple agents, such as multiple processor cores, multiple L2 caches, and multiple other logic blocks, to communicate with each other within the chip. Each ring data path is 1012 bits wide in one direction.

FIG. 9B is an enlarged view of a part of the processor core of FIG. 9A according to a plurality of embodiments of the present invention. FIG. 9B includes the L1 data cache 906A, which is part of the L1 cache 906, as well as further details regarding the vector unit 910 and the plurality of vector registers 914. Specifically, the vector unit 910 is a 16-width vector processing unit (VPU) (see 16-width ALU928) that executes one or more of integer, single-precision floating and double-precision floating instructions. The VPU supports the reconstruction of multiple register inputs by the reconstruction unit 920, the digit conversion by the digit conversion units 922AB, and the duplication to the memory inputs by the duplication unit 924. Multiple write mask registers 926 allow multiple vector writes of the result to be described.

[Processor with integrated memory controller and graphics]
FIG. 10 is a block diagram of a processor 1000 according to a plurality of embodiments of the present invention. It may have more than one core, it may have an integrated memory controller, it may have a centralized image display. Multiple solid boxes in FIG. 10 show a processor 1000 with a single core 1002A, system agent 1010, or a set of one or more bus controller units 1016, and multiple dashed boxes additionally added selectively. , An alternative processor 1000 with a plurality of cores 1002A-N, a set of one or more integrated memory controller units 1014 within a system agent unit 1010, and a special purpose logic 1008.

Thus, different implementations of the processor 1000 are: 1) a CPU with special purpose logic 1008, which is centralized image display and / or scientific (throughput) logic (which may include one or more cores), and one. Or multiple general purpose cores (eg, general purpose in-order cores, general-purpose out-of-order cores, combinations of the two) cores 1002A-N, 2) Many special intended primarily for graphics and / or scientific (throughput). It may include a coprocessor having a core 1002A-N which is an application core, and 3) a coprocessor having a core 1002A-N which is a large number of general-purpose in-order cores. Thus, the processor 1000 may be a general purpose processor, coprocessor or, for example, a network or communication processor, compression engine, graphics processor, GPGPU (general purpose graphics processing unit), high throughput multi-integrated core (MIC) coprocessor (30 or more). It may be a special purpose processor such as (including the core of), an embedded processor, and the like. The processor may be mounted on one or more chips. The processor 1000 may be part of and / or be mounted on one or more substrates using any of a number of processing techniques such as, for example, BiCMOS, CMOS or MIMO. ..

The memory hierarchy is one or more levels within an external memory (not shown) concatenated into multiple cores, one or more shared cache units 1006 or a set thereof, and a set of multiple integrated memory controller units 1014. Includes cache. A set of multiple shared cache units 1006 is one or more medium level caches, last level caches (LLC) such as secondary (L2), tertiary (L3), quaternary (L4) or other multiple level caches. ) And / or a combination thereof. In one embodiment, the ring-based interconnect unit 1012 interconnects the centralized image display logic 1008, a set of multiple shared cache units 1006 and the system agent unit 1010 / integrated memory controller unit 1014, but in a plurality of alternative embodiments. May use any number of well-known techniques for interconnecting such plurality of units. In one embodiment, coherency is maintained between one or more cache units 1006 and a plurality of cores 1002A-N.

In some embodiments, one or more of the plurality of cores 1002A-N can be multithreaded. The system agent 1010 includes a plurality of these components that tune and operate a plurality of cores 1002A-N. The system agent unit 1010 may include, for example, a power control unit (PCU) and a display unit. The PCU may be, or may include, the logic and components required to adjust the power states of the plurality of cores 1002A-N and the centralized image display logic 1008. The display unit is for driving one or more externally connected displays.

The plurality of cores 1002A-N may be homogeneous or heterogeneous with respect to the architectural instruction set, i.e., two or more of the plurality of cores 1002A-N are capable of executing the same instruction set. Others may be able to execute only that instruction set or a subset of different instruction sets.

[Exemplary multiple computer architectures]
11-14 are block diagrams of a plurality of exemplary computer architectures. Multiple laptops, multiple desktops, multiple handheld PCs, multiple personal digital assistants, multiple engineering workstations, multiple servers, multiple network devices, multiple network hubs, multiple switches, multiple embedded processors, Multiple Digital Signal Processors (DSPs), Multiple Graphics Devices, Multiple Video Game Devices, Multiple Set-Top Boxes, Multiple Microcontrollers, Multiple Mobile Devices, Multiple Portable Media Players, Multiple Handheld Devices and Various Others Other system designs and configurations known in the art for multiple electronic devices are also suitable. In general, a variety of systems or electronic devices that can incorporate processors and / or other execution logic, as disclosed herein, are generally suitable.

Here, with reference to FIG. 11, a block diagram of the system 1100 according to an embodiment of the present invention is shown. The system 1100 may include one or more processors 1110 and 1115 coupled to the controller hub 1120. In one embodiment, the controller hub 1120 comprises a graphics memory controller hub (GMCH) 1190 and an input / output hub (IOH) 1150 (which may be on separate chips), the GMCH 1190 having the memory 1140 and the coprocessor 1145. The IOH 1150 concatenates a plurality of input / output (I / O) devices 1160 to the GMCH 1190, including concatenated memory and a plurality of graphics controllers. Alternatively, the memory and one or both of the graphics controllers are integrated within the processor (as described herein), the memory 1140 and the coprocessor 1145 are directly coupled to the processor 1110 and the controller hub. The 1120 has an IOH 1150 on a single chip.

The selective nature of the additional processor 1115 is shown in FIG. 11 by a plurality of dashed lines. Each processor 1110 and 1115 may include one or more of the plurality of processor cores described herein, or may be several versions of the processor 1000.

The memory 1140 may be, for example, a dynamic random access memory (DRAM), a phase change memory (PCM), or a combination thereof. For at least one embodiment, the controller hub 1120 is a processor 1110, via a multi-drop bus such as a front-side bus (FSB), a point-to-point interface such as a quickpath interconnect (QPI), or a similar connection 1195. Communicate with 1115.

In one embodiment, the coprocessor 1145 is a special purpose processor such as, for example, a high throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor and the like. In one embodiment, the controller hub 1120 may include a centralized image display accelerator.

There can be various differences between the physical resources 1110 and 1115 with respect to different criteria of benefit, including architecture, microarchitecture, temperature, power consumption characteristics and the like.

In one embodiment, the processor 1110 executes a plurality of instructions controlling a plurality of common types of data processing operations. A plurality of coprocessor instructions may be incorporated in a plurality of instructions. Processor 1110 recognizes these plurality of coprocessor instructions as of the type to be executed by the attached coprocessor 1145. Accordingly, the processor 1110 issues these plurality of coprocessor instructions (or multiple control signals representing the plurality of coprocessor instructions) to the coprocessor 1145 on the coprocessor bus or other interconnect. The coprocessor 1145 receives and executes a plurality of received coprocessor instructions.

Here, with reference to FIG. 12, a block diagram of a first, more specific, exemplary system 1200 according to an embodiment of the present invention is shown. As shown in FIG. 12, the multiprocessor system 1200 is a point-to-point interconnect system and includes a first processor 1270 and a second processor 1280 coupled via a point-to-point interconnect 1250.

Each of the processors 1270 and 1280 may be several versions of the processor 1000. In one embodiment of the invention, the processors 1270 and 1280 are processors 1110 and 1115, respectively, and the coprocessor 1238 is a coprocessor 1145. In another embodiment, the processors 1270 and 1280 are the processor 1110 and the coprocessor 1145, respectively.

Processors 1270 and 1280 are shown as including integrated memory controller (IMC) units 1272 and 1282, respectively. Processor 1270 further includes point-to-point (PP) interfaces 1276 and 1278 as part of its plurality of bus controller units, as well as a second processor 1280 with PP interfaces 1286 and 1288. include. Processors 1270 and 1280 may exchange information via a point-to-point (PP) interface 1250 using the PP interface circuits 1278 and 1288. As shown in FIG. 12, IMC1272 and 1282 connect multiple processors to separate memory, i.e., memory 1232 and memory 1234 which can be part of the main memory locally attached to the individual processors.

Each of the plurality of processors 1270, 1280 may exchange information with the chipset 1290 via individual PP interfaces 1252, 1254 using multiple point-to-point interface circuits 1276, 1294, 1286, 1298. .. The chipset 1290 may selectively exchange information with the coprocessor 1238 via the high performance interface 1239. In one embodiment, the coprocessor 1238 is a special purpose processor such as, for example, a high throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor and the like.

A shared cache (not shown) may be contained inside either processor or outside both processors, but the local cache for either or both processors, even if the processor is in low power mode. It is connected to multiple processors via a PP interconnect so that information can be stored in a shared cache.

The chipset 1290 may be connected to the first bus 1216 via the interface 1296. In one embodiment, the first bus 1216 may be a bus such as a peripheral component interconnect (PCI) bus or a PCI Express bus or another 3rd generation I / O interconnect bus, but the scope of the invention is this. Not limited to.

As shown in FIG. 12, various I / O devices 1214 may be coupled to the first bus 1216 along with a bus bridge 1218 that connects the first bus 1216 to the second bus 1220. In one embodiment, multiple coprocessors, multiple high throughput MIC processors, multiple accelerators for GPGPU (eg, multiple graphics accelerators or multiple digital signal processing (DSP) units, etc.), multiple field programmable gate arrays or any. One or more additional processors 1215, such as other processors, are connected to the first bus 1216. In one embodiment, the second bus 1220 may be a Low Pin Count (LPC) bus. Various devices including, for example, a storage unit 1228 such as a keyboard and / or mouse 1222, multiple communication devices 1227, and disk drives, or other high capacity storage devices that may contain multiple instructions / codes and data 1230. , In one embodiment, it may be connected to the second bus 1220. Further, the audio I / O 1224 may be connected to the second bus 1220. Note that a plurality of other architectures are applicable. For example, instead of the point-to-point architecture of FIG. 12, the system may implement a multi-drop bus or other such architecture.

Here, with reference to FIG. 13, a block diagram of a second, more specific, exemplary system 1300 according to an embodiment of the present invention is shown. Similar elements in FIGS. 12 and 13 are given similar reference numbers, and the particular embodiment of FIG. 12 is omitted in FIG. 13 so as not to interfere with the other aspects of FIG. Has been done.

FIG. 13 shows that processors 1270, 1280 may include integrated memory and I / O control logic (“CL”) 1272 and 1282, respectively. Therefore, CL1272, 1282 includes a plurality of integrated memory controller units and includes I / O control logic. FIG. 13 shows that not only the memories 1232, 1234 are connected to CL1272, 1282, but the plurality of I / O devices 1314 are also connected to the plurality of control logics 1272, 1282. The plurality of legacy I / O devices 1315 are coupled to the chipset 1290.

Here, with reference to FIG. 14, a block diagram of the SoC1400 according to the embodiment of the present invention is shown. Similar elements in FIG. 10 are given similar reference numbers. Also, the plurality of dashed boxes are selective functions on multiple more advanced SoCs. In FIG. 14, the interconnect unit 1402 includes an application processor 1410 including a set of one or more cores 202A-N and a shared cache unit 1006, a system agent unit 1010, a bus controller unit 1016, an integrated memory controller unit 1014, and a centralized image display. One or more coprocessors 1420 or sets thereof, which may include logic, image processors, audio processors and video processors, static random access memory (SRAM) unit 1430, direct memory access (DMA) unit 1432 and one or more externals. It is connected to a display unit 1440 for connecting to a display. In one embodiment, the coprocessor 1420 includes special purpose processors such as, for example, network or communication processors, compression engines, GPGPUs, high throughput MIC processors, embedded processors and the like.

Multiple embodiments of the plurality of mechanisms disclosed herein may be implemented in a combination of hardware, software, firmware or such multiple implementation approaches. A plurality of embodiments of the present invention include a plurality of programmable devices comprising at least one processor, a storage system (including volatile and non-volatile memory and / or a plurality of storage elements), at least one input device and at least one output device. It may be implemented as multiple computer programs or program code running on the system.

A program code, such as the code 1230 shown in FIG. 12, may be applied to a plurality of input instructions in order to perform the plurality of functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC) or a microprocessor.

The program code may be implemented in a high-level procedural or object-oriented programming language to communicate with the processing system. The program code may be further implemented in assembly or machine language, if desired. In practice, the mechanisms described herein are not limited to any particular programming language to the extent. In either case, the language may be a compiled language or an interpreted language.

One or more aspects of at least one embodiment may be implemented by a plurality of representational instructions stored on a machine-readable medium representing various logics in the processor, such instructions to the machine. When read, it causes the machine to assemble the logic to perform the techniques described herein. Such representations, known as "IP cores," are stored on tangible machine-readable media, supplied to various customers or manufacturing plants, and loaded into multiple manufacturing machines that actually produce the logic or processor. May be.

Such machine-readable storage media are, but are not limited to, a plurality of hard disks, a plurality of floppy (registered trademark) disks, a plurality of optical disks, a plurality of compact disk read-only memories (CD-ROMs), and a plurality of rewritable compact disks (s). Any other type of disk, including CD-RW) and multiple magnetic optical disks, multiple semiconductor devices such as multiple read-only memories (ROMs), multiple dynamic random access memories (DRAMs), multiple static random access memories. (SRAM), multiple erasable programmable ROMs (EPROMs), multiple flash memories, multiple erasable programmable ROMs (EEPROMs), phase change memories (PCMs), multiple random access memories such as multiple magnetic or optical cards (s). Non-temporary and tangible plurality of articles manufactured or formed by a machine or device, including storage media such as RAM), or any other type of media suitable for storing multiple electronic instructions. May include the configuration of.

Accordingly, a plurality of embodiments of the present invention define a plurality of structures, a plurality of circuits, a plurality of devices, a plurality of processors and / or a plurality of system functions including a plurality of instructions or described herein. Further includes non-temporary and tangible machine-readable media containing design data such as a hardware description language (HDL). Such plurality of embodiments may be referred to as a plurality of program products.

[Emulation (including binary conversion, code morphing, etc.)]
In some cases, instruction transducers may be used to convert instructions from a source instruction set to a target instruction set. For example, an instruction transducer may convert, morph, convert an instruction into one or more other instructions to be processed by the core (eg, using dynamic binary translation, including static binary translation, dynamic compilation). It may be emulated or converted in other ways. The instruction transducer may be implemented in software, hardware, firmware or a combination thereof. The instruction transducer may be on the processor, off the processor, or partly on the processor and partly off the processor.

FIG. 15 is a block diagram comparing the use of a software instruction converter according to a plurality of embodiments of the present invention, which converts a plurality of binary instructions in a source instruction set into a plurality of binary instructions in a target instruction set. In the illustrated embodiment, the instruction converter is a software instruction converter, but instead, the instruction converter may be implemented in software, firmware, hardware or various combinations thereof. FIG. 15 shows a program of high-level language 1502 that can be compiled with the x86 compiler 1504 to generate x86 binary code 1506 that can be inherently executed by a processor with at least one x86 instruction set core 1516. In order for a processor with at least one x86 instruction set core 1516 to produce substantially the same results as an Intel processor with at least one x86 instruction set core, (1) the instruction set of the Intel x86 instruction set core. Most, or (2) compatiblely run or others of other software intended to run on Intel processors with multiple object code versions of multiple applications or at least one x86 instruction set core. Represents any processor capable of performing a plurality of functions substantially the same as an Intel processor having at least one x86 instruction set core by processing in the above manner. The x86 compiler 1504 is a compiler capable of producing x86 binary code 1506 (eg, object code) that can be run on a processor 1516 with at least one x86 instruction set core with or without further linking. show. Similarly, FIG. 15 executes a MIPS instruction set from a processor 1514 (eg, MIPS Technologies, Sunnyvale, California) that does not have at least one x86 instruction set core, and / or Sunnyvale, California. An alternative instruction set compiler 1508 is used to generate an alternative instruction set binary code 1510 that can be inherently executed by a processor with multiple cores that executes an ARM instructions set from ARM Holdings. The program of the high-level language 1502 that can be compiled is shown. The instruction converter 1512 is used to translate x86 binary code 1506 into code that can be inherently executed by a processor 1514 that does not have an x86 instruction set core. This converted code is unlikely to be the same as the alternative instruction set binary code 1510 because it is difficult to manufacture an instruction converter that can do this, however, the converted code does general operation. Achieved and complemented by multiple instructions from an alternative instruction set. Thus, the instruction converter 1512 is software, firmware, hardware that causes a processor or other electronic device without a x86 instruction set processor or core to execute x86 binary code 1506 through emulation, simulation, or any other processing. Represents wear or a combination of these.

Within the scope of the description and claims, the terms "concatenation" and / or "connection" are used in conjunction with these multiple derivatives. It should be understood that these terms are not intended as synonyms for each other. Rather, in certain embodiments, "connection" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Connecting" may mean that two or more elements are in direct physical or electrical contact. However, "linkage" may further mean that two or more elements do not come into direct contact with each other, but are interlocked or linked to each other. For example, the execution unit may be linked to a register or decoder via one or more intervening components. In a plurality of figures, a plurality of arrows are used to indicate a plurality of connections and / or a plurality of connections.

Within the scope of the description and claims, the term "logic" may be used. As used herein, the term logic may include hardware, firmware, software, or various combinations thereof. Multiple examples of logic include integrated circuits, multiple special purpose integrated circuits, multiple analog circuits, multiple digital circuits, multiple programmed logic devices, multiple memory devices containing multiple instructions, and the like. In some embodiments, the logic may include a plurality of transistors and / or a plurality of gates, potentially with a plurality of other circuit components (eg, incorporated into a plurality of semiconductor materials).

In the above description, a number of specific details have been presented to provide a good understanding of the plurality of embodiments. However, other embodiments are feasible without relying on some of these specific details. The scope of the present invention is not determined by the specific examples described above, but only by the following claims. All equal relationships to those shown in the drawings and described herein are contained within the embodiments. In other examples, details are omitted so that well-known circuits, structures, devices, and operations do not interfere with understanding in the form of block diagrams or explanations. There is. In some cases where multiple components are shown, they may be integrated into a single component. In some cases a single component is shown and described, this single component may be separated into two or more components.

The specific methods disclosed herein are shown and described in basic form, but operations are selectively added to and / or removed from the methods. You may. Further, although a particular order of operations may have been shown and / or described, another embodiment of the particular operation performs the particular operation in a different order. Can be combined, multiple specific operations can be overlapped, and so on.

A particular operation may be performed by multiple hardware elements and / or yields a hardware element programmed by an instruction to perform multiple operations (eg, a processor, a portion of a processor, etc.). And / or may be embodied in machine-executable instructions that can be used to bring. Hardware elements may include general purpose or special purpose hardware elements. Multiple operations may be performed by a combination of hardware, software and / or firmware. A hardware element executes and / or processes an instruction and performs an operation in response to the instruction (eg, in response to one or more microinstructions or other control signals derived from the instruction). It may include specific or specific logic (eg, potentially a circuit combined with software and / or firmware) that is capable of operating in such a manner.

Throughout the present specification, the references "one embodiment", "embodiment", "one or more embodiments", "several embodiments" include, for example, specific functions in the practice of the present invention. It may be, but it does not necessarily have to be included. Similarly, in the description, the various features, optionally in a single embodiment, figure or description thereof, are intended to simplify disclosure and aid understanding of various progressive embodiments. Grouped by. This disclosure method, however, is not construed to reflect the intent that the invention requires more functionality than is expressly defined in each claim. Rather, the progressive embodiments are part of the function of a single disclosed embodiment, as reflected in the claims below. Therefore, the scope of claims, in which each claim is independent as an embodiment, following the detailed description, is thereby clearly incorporated into this detailed description.

The following sections and / or examples relate to further embodiments. The details and / or examples of the sections may be used in any part of one or more embodiments.

In one embodiment, the first device comprises a plurality of cores and shared core extension logic linked to each of the plurality of cores. The shared core extension logic has shared data processing logic shared by each of the plurality of cores. The first device further includes instruction execution logic for each of the plurality of cores that calls the shared core extension logic in response to the shared core extension call instruction. The call causes the shared data processing logic data processing to be performed on behalf of the corresponding core.

The plurality of embodiments include a first device further including a plurality of shared core extended command registers concatenated with instruction execution logic and shared core extended logic, and a shared core extended call instruction is a plurality of shared core extended command registers. Shows one and more parameters.

The plurality of embodiments include one of the first devices described above, wherein the instruction execution logic responds to the shared core extended call instruction and is shown a shared core extended command based on the indicated parameters. Store data in registers.

The plurality of embodiments include one of the first devices described above, in which the instruction execution logic responds to the shared core extended call instruction and in the indicated shared core extended command register a call attribute pointing to the call attribute information. Stores a pointer to a pointer field, a pointer to an input data operand pointer field that points to an input data operand, and a pointer to an output data operand pointer field that points to an output data operand.

The plurality of embodiments include one of the first devices described above, in which the shared core extension logic provides the status of the call to the indicated shared core extension command register based on the data processing associated with the call. Contains a status field to be used, and a progress field that provides the progress of the call.

The plurality of embodiments include one of the first devices described above, and the shared core extended call instruction comprises a macro instruction of an instruction set of a plurality of cores.

The plurality of embodiments include any of the first devices described above, and the shared data processing logic includes at least one vector execution unit.

The plurality of embodiments include any of the first devices described above, and the shared data processing logic includes data processing logic that is not found in the plurality of cores.

The plurality of embodiments include one of the first devices described above, wherein the instruction execution logic follows a routine in memory that produces at least one output data structure in response to a shared core extended call instruction. Call the shared core extension logic to perform data processing on one input data structure.

The plurality of embodiments is for synchronizing the memory management unit (MMU) of the first core of a plurality of cores, the shared core expansion MMU of the shared core expansion logic, and the MMU of the first core and the shared core expansion MMU. Includes any of the first devices described above, further comprising a hardware interface between a first core MMU and a shared core extended MMU that exchanges a plurality of sync signals in hardware.

A plurality of embodiments include a memory management unit (MMU) of the first core of a plurality of cores, a shared core extension MMU of the shared core expansion logic, and a page fault corresponding to a call from the first core. Includes any of the first devices described above, further including an interface between the first core MMU and the shared core extended MMU that routes from the extended MMU to the first core MMU.

The plurality of embodiments includes any of the first devices described above, further comprising hardware scheduling logic that schedules multiple calls to the shared data processing logic from the plurality of cores, along with shared core extension logic on the die.

In one embodiment, the first method comprises receiving a shared core extended call instruction within the core of a processor having a plurality of cores. The shared core extended call instruction causes the core to call the shared core extended logic shared by multiple cores. The call causes data processing to be performed. A shared core extended call instruction indicates a shared core extended command register and indicates multiple parameters that specify the data processing to be performed. The shared core extension logic is called in response to a shared core extension call instruction so that data processing is performed. The step of calling the shared core extension logic involves storing data in the shared core extension command register indicated by the instruction, based on multiple parameters indicated by the instruction.

In a plurality of embodiments, the stage of receiving an instruction includes the stage of receiving a non-block shared core extension call instruction, and the shared core extension logic accepts the data processing to be executed, and then the non-block shared core extension is performed in the core. Includes a first method, further comprising the step of retiring the call instruction.

In the plurality of embodiments, the stage of receiving the instruction includes the stage of receiving the block shared core extended call instruction, and the stage of retiring the block shared core extended call instruction in the core after the shared core extension logic completes the data processing. The first method is included, further comprising.

The plurality of embodiments include a step of receiving an instruction including a step of receiving a block shared core extended call instruction, indicating a timeout value at which the block shared core extended call instruction releases the indicated shared core extended command register. Including the first method.

In a plurality of embodiments, the shared core extended call instruction comprises a macro instruction of the core instruction set, and the shared core extended command register comprises any of the plurality of first methods described above comprising an architecture register.

The plurality of embodiments are based on a plurality of parameters, the stage of storing data in the indicated shared core extended command register is the stage of storing a pointer in the call attribute pointer field pointing to the call attribute information, and the stage of storing the input data operand. It comprises one of a plurality of first methods described above, comprising storing a pointer in a pointing input data operand pointer field and storing a pointer in an output data operand pointer field pointing to an output data operand.

The plurality of embodiments further include shared core extension logic that stores the data in the indicated shared core extension register based on the data processing associated with the call, and the stage of storing the data provides the status of the call. Multiple described above, including a step of storing the status in the status field of the indicated register, and a step of storing the progress in the progress field of the indicated register to provide the progress of the call. Includes any of the first methods of.

The plurality of embodiments includes any of the plurality of first methods described above. The calling step includes calling the shared core extension logic to perform data processing on at least one input data structure in memory according to a routine that produces at least one output data structure in memory.

A plurality of embodiments are a step of synchronizing a core memory management unit (MMU) with a shared core expansion MMU of shared core expansion logic by exchanging synchronization signals in hardware between the MMU and the shared core expansion MMU. Includes any of the plurality of first methods described above, further comprising:

The plurality of embodiments includes one of the first method described above, further comprising the step of routing the page fault corresponding to the call from the shared core extended memory management unit (MMU) to the core MMU.

A plurality of embodiments include a step of receiving a supply core extended stop instruction indicating a shared core extended command register and a supply core extended stop instruction in response to the supply core extended stop instruction before receiving the shared core extended call command. Includes any of the first methods described above, further comprising aborting the data processing corresponding to the shared core extended command register indicated by and releasing the shared core extended command register.

A plurality of embodiments include a step of receiving a shared core extended read instruction indicating a shared core extended command register after receiving a shared core extended call instruction, and a shared core extended read instruction in response to the shared core extended read instruction. It comprises any of the first methods described above, further comprising reading the data processing completion status from the shared core extended command register shown.

In one embodiment, the machine-readable storage medium stores one or more instructions that, when executed by the machine, cause the machine to perform any of the first methods described above.

In one embodiment, the device is configured or operable to perform any of the plurality of first methods described above.

A plurality of embodiments include a first system comprising a processor and a dynamic random access memory (DRAM) coupled to the processor. The processor includes a plurality of cores and shared core extension logic linked to each of the plurality of cores. The shared core extension logic has shared data processing logic shared by each of the plurality of cores. The processor further includes instruction execution logic for each of the plurality of cores that calls the shared core extension logic in response to the shared core extension call instruction. The call causes the shared data processing logic to perform data processing on behalf of the corresponding core.

In a plurality of embodiments, the shared core extended call instruction includes a first system including macro instructions of an instruction set of a plurality of cores.

The plurality of embodiments further include a shared core extended command register on a plurality of architectures concatenated with an instruction execution logic and a shared core extended logic, wherein the shared core extended call instruction is one of the plurality of shared core extended command registers. Includes one of the plurality of first systems described above, indicating a plurality of parameters.

Claims (20)

It ’s a processor,
With multiple digital signal processor cores (multiple DSP cores),
A shared vector processing circuit connected to the plurality of DSP cores and shared by the plurality of DSP cores.
A memory management circuit for translating a virtual address in a virtual address space shared by the plurality of DSP cores and the shared vector processing circuit, wherein the virtual address is converted into a physical address of a system memory. With the memory management circuit,
Each DSP core
A decoder for decoding the instructions of the first thread and the second thread, and
A core execution circuit for executing one or more instructions of the first thread and the second thread, and
It has a context data for the first thread and a core register file for storing the context data for the second thread.
The shared vector processing circuit is
A first plurality of registers for storing a copy of the context data for the first thread, and
A second plurality of registers for storing a copy of the context data for the second thread, and
A processor having a single instruction and a plurality of data execution circuits (SIMD execution circuits) for executing a process for the first thread and the second thread. The processor according to claim 1, wherein the memory management circuit has a translation lookaside buffer (TLB) for caching a translation from a virtual address to a physical address. The DSP core is for storing the context data as a part of the context of the first thread and the context data as a part of the context of the second thread in the core register file. The processor according to claim 1 or 2. The processing performed by the SIMD execution circuit is based on an extension to the instruction set architecture (ISA).
The processor according to any one of claims 1 to 3. The processor according to any one of claims 1 to 4 , wherein the first plurality of registers and the second plurality of registers are architecturally visible registers of an instruction set architecture (ISA). The processor according to any one of claims 1 to 5 , wherein the shared vector processing circuit has a histogram circuit for performing a histogram calculation. The processor according to any one of claims 1 to 6 , wherein the shared vector processing circuit has a matrix multiplication circuit. The processor according to any one of claims 1 to 7 , wherein the shared vector processing circuit has a total absolute difference circuit. The processor according to any one of claims 1 to 8 , further comprising a first interconnect for connecting the plurality of DSP cores to the shared vector processing circuit. 9. The processor of claim 9 , further comprising a second interconnect for connecting the shared vector processing circuit to a memory subsystem that includes one or more levels of shared memory. System memory for storing instructions and data,
A system comprising the processor according to any one of claims 1 to 10 , which is connected to the system memory. 11. The system of claim 11 , further comprising a storage device connected to the processor to store instructions and data. 22. The system of claim 11 or 12 , further comprising an input / output (I / O) interconnect for connecting the processor to one or more I / O devices. The system according to any one of claims 11 to 13 , wherein the system memory has a dynamic random access memory (DRAM). The system according to any one of claims 11 to 14 , further comprising a graphics processor connected to the processor to perform a graphics processing operation. The system according to any one of claims 11 to 15 , further comprising a network processor connected to the processor. The system according to any one of claims 11 to 16 , further comprising an audio input / output device connected to the processor. The system further comprises a second processor connected to the DSP core of the processor.
The processor is the first processor and
The first processor recognizes the type of instruction to be processed by the second processor .
The system according to any one of claims 11 to 17 . 18. The system of claim 18 , further comprising a shared cache shared by the first processor and the second processor. The system according to any one of claims 11 to 19 , further comprising a compression circuit connected to the processor.

Images