Dynamic reconstruction of multi-core processor to unified core

Abstract

The invention discloses dynamic reconstruction of a multi-core processor to a unified core. A first thread is executed in a first pipeline of a first core of an integrated circuit (IC). The first core includes a first set of hardware structures. The second thread executes in a second pipeline of a second core of the IC. The second core includes a second set of hardware structures. In response to a command to operate an IC having a unified core, the first core is combined with the second core to obtain the unified core. To unify the first core, the first pipeline is unified with the second pipeline to obtain a unified pipeline, and the first set of hardware structures is unified with the second set of hardware structures to obtain a unified set of hardware structures. A single thread is executed in a unified pipeline of a unified core using the unified set of hardware structures.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to Greek patent application No. 20240100127, filed on February 19, 2024, entitled “DYNAMIC RECONFIGURATION OF A MULTI-CORE PROCESSOR TO A UNIFIED CORE,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] Embodiments of the present disclosure relate generally to processors, and more particularly, to reconfiguration of a processor from a unified core to multiple cores or from multiple cores to a unified core. Background Art

[0004] High-performance central processing unit (CPU) cores typically increase performance at the expense of increasing the chip area occupied by the CPU core. The performance of a CPU core can be increased relative to its die area size. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1A A block diagram of an integrated circuit (IC) operating two cores according to aspects and embodiments of the present disclosure is shown.

[0006] Figure 1B A block diagram of an IC operating a unified core according to aspects and embodiments of the present disclosure is shown.

[0007] Figure 1C A block diagram of an IC operating three cores according to aspects and embodiments of the present disclosure is shown.

[0008] Figure 1D A block diagram of an IC operating a unified core according to aspects and embodiments of the present disclosure is shown.

[0009] Figure 1E A block diagram of an IC including processors configured as separate cores and processors configured as a unified core is shown, according to aspects and embodiments of the present disclosure.

[0010] Figure 2 A block diagram of a processor according to aspects and embodiments of the present disclosure is shown.

[0011] Figure 3 A block diagram of a processor front end according to aspects and embodiments of the present disclosure is shown.

[0012] Figure 4 A block diagram of a core in a processor according to aspects and embodiments of the present disclosure is shown.

[0013] Figure 5 A block diagram of a memory subsystem of a processor according to aspects and embodiments of the present disclosure is shown.

[0014] Figure 6 A flowchart illustrating an example method for dynamically reconfiguring a processor from multiple cores to a unified core according to aspects and embodiments of the present disclosure is shown.

[0015] Figure 7 A flowchart illustrating an example method for dynamically reconfiguring a processor from a unified core to multiple cores according to aspects and embodiments of the present disclosure is shown.

[0016] Figure 8 is a block diagram illustrating an exemplary computer system according to aspects and embodiments of the present disclosure. DETAILED DESCRIPTION

[0017] Modern CPU cores are constantly evolving to achieve higher performance through a variety of techniques. In many cases, high-performance processing cores achieve improved performance at the expense of area and power. For example, high-performance processing cores can add more hardware resources (e.g., execution units, cache, interconnects, etc.), thereby increasing the total die area used by the processing core while reducing performance improvements. As a result, some high-performance CPU cores can be inefficient in terms of performance per square millimeter (mm) of die area and performance per watt.

[0018] Conventional techniques utilize a capability called simultaneous multithreading (SMT) or hyperthreading to gain additional performance by executing multiple processes (e.g., threads) on a single processing core. For example, a single-core CPU may be able to execute two threads by utilizing SMT techniques. However, conventional SMT techniques have many disadvantages and may lead to design and architectural issues. For example, conventional SMT techniques share and dynamically allocate resources (e.g., execution units, pipeline stages, register files, etc.) between threads executing on the same processing core. In addition, CPUs employing SMT may be vulnerable to side-channel attacks that exploit this dynamic resource sharing and resource allocation to effectively retrieve data that should not be accessible to other threads running on the same core.

[0019] In another example, the dynamic resource sharing implemented by conventional SMT may cause one thread (e.g., instruction sequence) to negatively impact the performance of another thread running on the same CPU core. For example, if multiple threads compete for the same resource simultaneously, performance may be degraded and stalls may result, thereby reducing the overall efficiency of the CPU core.

[0020] In another example, SMT CPU cores share pipelines and hardware structures in the CPU core that can cause design complexity. Specifically, shared pipelines and hardware structures can lead to deadlock (e.g., multiple threads are blocked indefinitely because each thread waits for resources held by the other party), livelock (e.g., multiple threads are executing but cannot make progress due to conflicts with other threads), and starvation problems (e.g., one thread always uses less resources than another thread). These problems can be solved by careful design of resource allocation, thread scheduling, and dependency management. Designing such mechanisms can be challenging and imposes significant overhead in terms of design complexity. Therefore, adding additional performance features to SMT CPU cores can be a significant obstacle for CPU designers.

[0021] Aspects and embodiments of the present disclosure address the above-mentioned and other deficiencies of conventional SMT CPU systems by providing a technology that enables a processor to be dynamically reconfigured between a multi-core processor (e.g., executing multiple threads on multiple cores) and a unified core processor (e.g., executing a single thread on a unified core). A multi-core processor can include two or more independent processing units (e.g., cores) on a single die. Each core can independently execute a thread (e.g., a process, an instruction sequence, etc.), thereby allowing multiple threads to be executed in parallel. Aspects and embodiments of the present disclosure enable resources (e.g., hardware structures, pipelines, etc.) to be statically partitioned between cores. In one embodiment, a processor can be dynamically reconfigured into a unified core processor. A unified core can be a single core that performs all computing tasks of the processor by executing a single thread on the unified core. A unified core can be a unification of multiple smaller cores. For example, a unified core can unify pipelines and hardware structures associated with multiple cores.

[0022] In at least one embodiment, a processor can be dynamically reconfigured from a multi-core processor (also referred to herein as "multi-core mode" or "multi-threaded mode") to a unified core processor (also referred to herein as "unified core mode" or "single-threaded mode"). For example, the processor can execute a first thread on a first pipeline in a first core of the processor and a second thread on a second pipeline in a second core of the processor. In response to a command to reconfigure to a unified core, the processor can flush the first and second pipelines to prepare for the unification of the first and second cores. This command can be received from the processor's system software. In at least one embodiment, this command can be received from firmware such as a basic input / output system (BIOS). In at least one embodiment, this command can be received from an application or other software source. In at least one embodiment, a hardware component can detect a condition that causes the processor to be reconfigured to a unified core. For example, the hardware component can detect that the second core has been inactive for more than a threshold number of clock cycles, thereby causing the processor to be reconfigured to a unified core. To unify the cores, the processor can unify the first pipeline with the second pipeline to obtain a unified pipeline, and unify the first hardware structure set with the second hardware structure set to obtain a unified hardware structure set. The processor can use the unified pipeline to execute a single thread (e.g., an active thread) on the unified core.

[0023] In some embodiments, a command to operate the processor with a unified core may be issued in response to determining that the second core has been in an inactive state for more than a threshold number of clock cycles (e.g., 50). For example, the processor may receive an instruction from the processor's system software indicating that the second thread is transitioning to an inactive state (e.g., a wait for interrupt (WFI) instruction, a HALT instruction, etc.), thereby causing the core (or a thread executing on the core) to enter an inactive state. The inactive state means that the core is not currently executing any instructions (e.g., not executing a thread) or not executing any tasks. This may be advantageous because unifying the cores can enable a single thread to achieve higher peak performance by executing on a wider unified core rather than on a non-unified core of a multi-core processor. When one of the cores is inactive, this can significantly improve the performance of the remaining active threads. For example, a first thread may execute at a rate of N instructions per cycle (N-wide) on a first core, while a second thread may execute at a rate of N instructions per cycle (N-wide) on a second core. When one of the threads / cores becomes inactive, the pipelines and hardware structures can be unified to obtain a 2N-wide unified core that can execute the remaining active threads on the unified pipeline at a rate of 2N instructions per cycle.

[0024] In at least one embodiment, a processor can be dynamically reconfigured from a unified core processor to a multi-core processor. For example, the processor can execute a first thread on a unified pipeline of a unified core of the processor. In response to a command, such as a command received from system software (e.g., an operating system (OS), a hypervisor, firmware, a BIOS, etc.) to reconfigure as a multi-core processor, the processor can refresh the unified pipeline to prepare for partitioning the unified core. To partition the unified core, the processor can statically partition the unified pipeline to obtain a first pipeline and a second pipeline, and partition the unified hardware structure set of the unified core into a first hardware structure set and a second hardware structure set. The processor can execute the first thread on the first core and the second thread on the second core. In at least one embodiment, the hardware structure set may include caches, translation lookaside buffers (TLBs), register files, queues, branch predictors, branch target buffers, execution units, schedulers, etc. Statically partitioned resources (e.g., hardware structures, pipelines, etc.) can allow separate threads to run independently on corresponding cores of the processor with minimal interaction and almost no resource sharing.

[0025] In some embodiments, a command to operate a processor with multiple cores may be issued in response to receiving an interrupt from system software or IC hardware indicating that a second thread is ready to execute on the processor. For example, a processor may receive an interrupt from an operating system that causes an inactive thread to become active ("wake up"). When the inactive thread is woken up, this can significantly improve the efficiency, throughput, and performance of the processor by allowing the processor to independently execute multiple threads in parallel on the processor. For example, a first thread may execute at a rate of 2N instructions per cycle on a unified core (2N wide), but may not have a workload that can utilize the entire width of the unified core. When the second thread is woken up, the pipeline and hardware structure can be statically partitioned to obtain a first N-wide core and a second N-wide core that can execute the first and second threads, respectively, on the partitioned pipeline at a rate of N instructions per cycle, and can more easily utilize the width of the partitioned pipeline than the combined pipeline width. This improves overall efficiency (e.g., performance per area, performance per watt, etc.), throughput, and performance.

[0026] The advantages of the technology disclosed herein include, but are not limited to, increasing the frequency of the processor by reducing the critical path of the design and the logic for selecting which thread will use which pipeline in a given cycle. This can be achieved by statically partitioning the pipeline so that each thread can execute on an independent pipeline (with minimal resource sharing between threads). Compared to conventional SMT methods that use a portion of each clock cycle to determine which thread will run on a given pipeline in a given cycle, this static pipeline partitioning can utilize the entire clock cycle to execute instructions. In addition, statically partitioning hardware structures (e.g., caches, branch predictors, etc.) can eliminate performance variation problems and security issues associated with resource sharing in conventional SMT designs. For example, by statically partitioning the structure and pipeline, deadlock, livelock, starvation problems, and other problems associated with conventional SMT can be avoided due to minimal interaction and resource sharing between threads. In another example, due to minimal resource sharing and increased thread isolation, it may be difficult to coordinate certain attacks (e.g., side channel attacks) commonly used against conventional SMT designs. Therefore, the technical effects of the present disclosure can also include more secure multi-threaded processors that limit or prevent the extraction of data associated with processors that share resources between multiple threads executing on the processor (e.g., through side channel attacks). Thus, aspects and embodiments of the present disclosure may provide flexibility in transitioning between executing multiple threads and a single thread on a processor while avoiding the drawbacks of conventional SMT designs.

[0027] It should be noted that various aspects of the above-described methods and systems will be described in detail below by way of example and not limitation. For the sake of simplicity and brevity only, the embodiments and examples provided below may refer to a dual-core processor configuration that can be reconstructed as a unified core. However, the embodiments and examples of the present disclosure may generally be applied to multi-core processors with any number of cores, as well as integrated circuit (IC) configurations having multiple multi-core processors that can transition between a multi-core mode and a unified core mode. For example, when describing the pipeline depth and width of a dual-core embodiment, a factor of 2 may be used for simplicity, but not as a limitation. For an N-core embodiment, this factor may be generalized to any value between 2 and N (including 2 and N).

[0028] Figure 1A A block diagram of an integrated circuit 100 (IC 100) operating two cores according to aspects and embodiments of the present disclosure is shown. IC 100 can be a general-purpose computing device (CPU, graphics processing unit (GPU), etc.), a special-purpose computing device (field programmable gate array (FPGA), application-specific integrated circuit (ASIC), etc.), etc. IC 100 is also referred to herein as processor 100, for purposes of illustration and not limitation, and it is noted that aspects and embodiments of the present disclosure can be applied to various computing devices, such as those mentioned above.

[0029] As shown, IC 100 includes core 110A and core 110B packaged on the same die. Core 110A and core 110B can each include a separate pipeline. Core 110A can implement pipeline 120A, and core 110B can implement pipeline 120B. Cores 110A and 110B and their respective pipelines can be statically partitioned so that each core independently executes a separate instruction sequence in parallel. For example, core 110A can execute a first thread (e.g., a first instruction sequence) on pipeline 120A, and core 110B can execute a second thread (e.g., a second instruction sequence) on pipeline 120B, so that the first thread does not affect the second thread executed on core 110B, and the second thread does not affect the first thread executed on core 110A. In an illustrative example, core 110A can independently execute the first thread on N-wide pipeline 120A with a bandwidth of N instructions per cycle. Core 110B may independently execute the second thread on N-wide pipeline 120B at a bandwidth of N instructions per cycle.

[0030] Core 110A includes a hardware structure set 130A, and core 110B includes a hardware structure set 130B. Each hardware structure set 130A and 130B may include one or more caches (e.g., L1 cache, L2 cache, etc.), buffers (e.g., translation lookaside buffer, branch target buffer, DCache miss tracker (DCMT), write-combining buffer (WCB), etc.), queues (e.g., load replay queue, issue queue, prefetch queue, etc.), register files, branch predictors, execution units, schedulers, etc., as described below with respect to Figure 2 、 Figure 3 and Figure 4 As shown in the figure, the hardware structures 130A and 130B provided on the IC 100 can be statically partitioned between the core 110A and the core 110B, respectively.

[0031] Figure 1BA block diagram of an IC 100 operating a unified core 110C according to aspects and embodiments of the present disclosure is shown. The unified core 110C includes a unified pipeline 120C and a unified hardware fabric set 130C. The unified pipeline 120C can be a combination of pipeline 120A and pipeline 120B, allowing the IC 100 to execute threads on a wider pipeline than pipelines 120A and 120B alone. For example, core 110A can independently execute a first thread on N-wide pipeline 120A at a rate of up to N instructions per cycle, and core 110B can independently execute a second thread on N-wide pipeline 120B at a rate of N instructions per cycle. The unified core 110C can execute the first thread, the second thread, or any other thread on the 2N-wide unified pipeline 120C at a rate of 2N instructions per cycle.

[0032] The set of unified hardware structures 130C may include one or more caches (e.g., L1 cache, L2 cache, etc.), buffers (e.g., translation lookaside buffer, branch target buffer, DCMT, WCB, etc.), queues (e.g., load replay queue, issue queue, prefetch queue, etc.), register files, branch predictors, execution units, schedulers, etc. The unified hardware structure 130C may include hardware structures 130A and 130B, so that the unified core 110C can utilize the entire hardware structure arranged on the IC. For example, the IC 100 may include caches (e.g., L1 instruction cache, L1 data cache, etc.). The unified core 110C can write / allocate, read, and otherwise access the entire cache arranged on the IC 100.

[0033] In at least one embodiment, IC 100 can dynamically Figure 1A The multi-core configuration transitions shown (eg, in response to commands) are about Figure 1B The unified core configuration shown, as described in Figure 6 In at least one embodiment, IC 100 can dynamically Figure 1B The unified core configuration changes (e.g., in response to a command) to Figure 1A Multi-core configuration, as shown below Figure 7 Described in detail. Figure 1A The IC 100 configurations are referred to herein as "multi-threaded mode," "multi-core mode," and "processor operating with two active threads," noting that each refers to an IC 100 (e.g., a processor) having multiple cores that are configured to execute separate threads on respective pipelines using respective sets of hardware resources, where the pipelines and hardware structure are statically partitioned on a per-core or per-thread basis. Figure 1BThe IC 100 configurations in are referred to herein as "single-threaded mode," "combined core," "unified core," "supercore," and "processor operating with one active thread," noting that each refers to an IC 100 (e.g., a processor) having a single unified core that is configured to execute threads on a unified pipeline using a corresponding unified set of hardware structures.

[0034] Figure 1C A block diagram of an IC 150 operating three cores according to aspects and embodiments of the present disclosure is shown. IC 150 includes core 160A, core 160B, and core 160C packaged on the same die. Cores 160A-C can each include a separate pipeline. Core 160A can implement pipeline 170A, core 160B can implement pipeline 170B, and core 160C can implement pipeline 170C. Cores 160A-C and their respective pipelines can be statically partitioned so that each core independently executes a separate instruction sequence in parallel. Cores 160A-C can each include a separate hardware architecture. Core 160A includes hardware architecture set 180A, core 160B includes hardware architecture set 180B, and core 160C includes hardware architecture set 180C. Hardware architectures 180A, 180B, and 180C can be statically partitioned between core 160A, core 160B, and core 160C, respectively.

[0035] Figure 1D A block diagram of IC 150 operating a unified core 160D according to aspects and embodiments of the present disclosure is shown. Unified core 160D includes a unified pipeline 170D and a unified hardware fabric set 180D. Unified pipeline 170D may be a combination of pipelines 170A-C, allowing IC 100 to execute threads on a wider pipeline than individual pipelines 170A-C. Unified hardware fabric set 180D may be a combination of hardware fabrics 180A-C.

[0036] The same techniques used to dynamically transition IC 100 between two cores and a unified core can be applied to reconfiguring IC 150 between three cores and a unified core. In at least one embodiment, aspects and embodiments of the present disclosure can implement more than three cores that can be reconfigured into a unified core. For example, an IC can include four cores that can be reconfigured into a unified core. Thus, aspects and embodiments of the present disclosure can generally be applied to multi-core configurations that can be reconfigured into a unified core.

[0037] Figure 1EA block diagram of an IC 190 is shown, which includes a processor 191A configured as a separate core and a processor 191B configured as a unified core. Processor 191A includes core 192A and core 192B packaged on the same processor 191A. Core 192A may include pipeline 193A and hardware structure 194A. Core 192B may include pipeline 193B and hardware structure 194B. Cores 192A and 192B and their respective pipelines and hardware structures can be statically partitioned so that each core independently executes a separate instruction sequence in parallel. In at least one embodiment, processor 191A can be reconfigured as a unified core in accordance with aspects and embodiments of the present disclosure.

[0038] Processor 191B may include a unified core 192C having a unified pipeline 193C and a unified hardware structure 194C. The unified pipeline 192C may be a combination of pipelines. The set of unified hardware structures 194C may be a combination of hardware structures. In at least one embodiment, according to aspects and embodiments of the present disclosure, processor 191B may be reconfigured as a separate core. It may be noted that some embodiments may be extended to multiple (e.g., two or more) processors provided on IC 190, such as processor 191A and processor 191B. The processors may be configured as a unified core or separate cores to form an IC 190 that can adapt to varying workloads.

[0039] The hardware structure described in this article, such as the following Figures 3 to 5The described hardware structure can be partitioned according to one or more methods. In at least one embodiment, a subset of the hardware structure can be managed using warp points or wrapping pointers. A wrapping point refers to an entry within a circular buffer where subsequent inserts or reads from the buffer wrap back to the beginning of the buffer to reuse memory space. For example, the hardware structure described herein may include one or more circular buffers, such as a reorder buffer. The ROB can be a circular first-in-first-out (FIFO) buffer that tracks out-of-order execution of instructions and ensures that instructions are retired in order. In an illustrative example, when a processor is running on a unified core with one active thread, the ROB can be a circular queue with a head pointer and a tail pointer. The head pointer points to the oldest instruction, and new instructions are added to the ROB at the entry pointed to by the tail pointer. When an instruction is added to the ROB 434, the tail pointer advances to the next available entry. When an instruction retires, the head pointer advances to reference the next instruction in the ROB. The wrapping point of the ROB can be located at the end of the ROB. The wrap point of the ROB can refer to a specific location within the ROB (e.g., the end of the ROB) where the index of the ROB 434 is reset to the beginning. In at least one embodiment, when a processor is reconfigured from multiple active threads to one active thread or from one active thread to multiple active threads, the wrap point of the ROB can be modified to statically partition the ROB. For example, when a processor is reconfigured from one active thread to two active threads (e.g., in a dual-core embodiment), the head pointer and tail pointer associated with the first thread can start at the first entry of the ROB and wrap back to the first entry of the ROB at a midpoint in the ROB. The head pointer and tail pointer associated with the second thread can start at the midpoint of the ROB and wrap back to the midpoint of the ROB at the last entry in the ROB. It will be understood that the ROB is used herein as an example and not as a limitation, and please note that other loop structures described herein may also be similarly partitioned using wrap pointers.

[0040] In at least one embodiment, a dynamically allocated random access structure (e.g., a subset of the cache and / or translation lookaside buffer described herein) can be partitioned into a predefined pattern (also referred to herein as "partitioned by way"). For example, when a processor operates with two active threads, the L1 instruction cache can be statically partitioned into a first partition and a second partition of equal or unequal size. When the processor operates in a multi-threaded mode, the first thread can write to and be allocated to L1 instruction cache entries within the first partition, while the second thread can write to and be allocated to L1 instruction cache entries within the second partition. It should be understood that the L1 instruction cache is used herein by way of example and not limitation, and it should be noted that other dynamically allocated random access structures described herein can also be similarly partitioned by way.

[0041] In at least one embodiment, the subset of HW structures described in the previous paragraph can be configured so that multiple threads can read from the entire subset of HW structures when running in multi-core mode. For example, dynamically allocated random access structures (e.g., caches, TLBs, etc.) can be configured so that multiple threads can have read access rights. In at least one embodiment, another subset of HW structures (e.g., branch predictors, register files, etc.) can be configured so that only the associated thread can read from the corresponding partitioned portion of the HW structure.

[0042] Because the L1 instruction cache is partitioned, for example, so that multiple threads have read access, a first thread and a second thread can read from the L1 instruction cache in parallel. For example, if either thread misses in the L1 instruction cache, it can send a request to retrieve data from the L2 cache within the memory subsystem. In at least one embodiment, an instruction fetch unit (IFU) can interface with the memory subsystem via a single bus. In some cases, the first thread and the second thread may miss the L1 instruction cache simultaneously, resulting in a conflict on the bus to the memory subsystem. In at least one embodiment, the IFU can resolve such conflicts using an arbitration scheme (e.g., round-robin arbitration) that does not allow for interaction between threads. For example, in the first case, when the threads simultaneously request access to the memory subsystem via the bus, the IFU can assign a priority to the first thread. In the second case, when the threads simultaneously request access to the memory subsystem via the bus, the IFU 310 can assign a priority to the second thread, and so on. Thus, the IFU can arbitrate access to the memory subsystem via a single shared bus in a time-multiplexed manner. In at least one embodiment, the IFU 310 can interface with the memory subsystem via multiple buses. For example, a first bus may be dedicated to a first thread, while a second bus may be dedicated to a second thread. It will be appreciated that arbitration of a request bus between caches is used herein by way of example and not limitation, and it is noted that the arbitration scheme described above may generally be applied to any bus (e.g., a request bus, a response bus, etc.) that multiple components may contend for access to a shared resource.

[0043] In at least one embodiment, random access structures (e.g., register files) can be partitioned by bank. For example, when a processor is running with one active thread, the thread can use two banks to access all registers, thereby avoiding port conflicts with different banks. When the processor is running with two active threads, each bank can be dedicated to one thread, thereby eliminating cross-thread port conflicts. This bank partitioning can be applied to other random access structures in the processor.

[0044] Figure 2A block diagram of a processor 200 according to aspects and implementations of the present disclosure is shown, comprising a front end 210, a mid-core 220, and a memory subsystem 230. The processor 200 can implement pipelined processing to retrieve, decode, and execute instructions from memory, as described in detail below. In at least one embodiment, the processor 200 can operate in single-threaded mode or multi-threaded mode. When operating in single-threaded mode, the processor 200 can run a single thread at the full width of the processor 200. When operating in multi-threaded mode, the processor 200 can run multiple threads at a reduced width. In order to achieve thread isolation between multiple threads, the structure and data path can be statically partitioned between the threads so that each thread processes instructions in a separate pipeline.

[0045] Branch Prediction

[0046] Figure 3 1 is a block diagram of a front end 210 of a processor (eg, processor 200) according to aspects and embodiments of the present disclosure. Figure 2 The front end 210 of the processor 200 includes a branch prediction unit 320 (BPU 320) for predicting whether a branch will be taken. A branch is a type of action that changes the execution path and determines the set of instructions to be executed next. Branches can occur as a result of instructions such as conditional branches, jumps, unconditional branches, etc. The BPU 320 may include a collection of various predictors and branch target buffers (BTBs). In at least one embodiment, each component of the BPU 320 (each branch predictor, each buffer, etc.) may be configured according to the above description of the branch target buffer. Figure 1E One or more of the methods described are statically partitioned so that each thread is associated with a separate branch prediction pipeline. Thus, each thread can issue mispredictions, invalidate instructions, flush its corresponding BPU pipeline, issue updates, etc., without affecting other threads. When a processor runs a single thread on a unified core, the unified core can utilize the entire BPU pipeline and any predictor structures (predictor, BTB, etc.) of the processor.

[0047] Instruction Fetch

[0048] Front end 210 includes an instruction fetch unit 310 (IFU 310) for fetching instructions from memory and passing them to subsequent stages of a processor (e.g., processor 200 or IC 100). In at least one embodiment, IFU 310 may maintain a register (referred to herein as a "program counter (PC)") for managing the addresses of instructions to be executed by the processor. IFU 310 may increment the PC to reference the next instruction to be fetched in the instruction sequence or update the PC based on certain instructions (e.g., branches, jumps, etc.). In at least one embodiment, IFU 310 may fetch instructions from main memory (e.g., dynamic random access memory (not shown)). In at least one embodiment, IFU 310 may fetch instructions from other memory in the memory hierarchy. For example, IFU 310 may fetch instructions from L1 instruction cache 312 located on the processor or from a memory subsystem (e.g., memory subsystem 230).

[0049] In at least one embodiment, the IFU 310 includes an L1 instruction cache 312 for temporarily storing frequently accessed instructions. For example, the IFU 310 can store instructions in the L1 instruction cache 312. Instructions can be retrieved from the L1 instruction cache 312 rather than subsequently reading the instructions from main memory. The L1 instruction cache 312 can operate based on the spatial and / or temporal locality of instructions to reduce the latency associated with accessing main memory to retrieve instructions.

[0050] In at least one embodiment, the IFU 310 includes an instruction translation lookaside buffer 314 (ITLB 314). The ITLB 314 is a hardware buffer used to cache virtual-to-physical address translations of instructions. The ITLB 314 stores a mapping between virtual instruction addresses and corresponding physical addresses associated with instructions fetched by the IFU 310. When the IFU 310 fetches an instruction from memory, the IFU 310 may first check the ITLB 314. If the IFU 310 determines that the virtual-to-physical mapping for the instruction is stored in the ITLB 314, the IFU 310 may retrieve the physical address corresponding to the instruction from the ITLB 314. If the IFU 310 determines that the virtual-to-physical mapping is not stored in the ITLB 314, the processor may retrieve the physical address from the memory subsystem. In at least one embodiment, according to one or more of the above methods, the L1 instruction cache 312, ITLB 314, and instruction fetch 316 pipeline may generally be statically partitioned and / or unified.

[0051] decoding

[0052] Instructions fetched by the IFU 310 at the instruction fetch 316 are provided to a decode queue 318 for instruction decoding. The front end 210 of the processor includes a decode queue 318 that is operatively coupled to receive instructions from the instruction fetch 316. The decode queue 318 can be a hardware structure (e.g., a first-in, first-out (FIFO) queue) for storing instructions prior to instruction decoding. In at least one embodiment, the decode queue 318 can be statically divided into a decode queue 318A and a decode queue 318N.

[0053] The front end 210 of the processor includes decode logic 330, which is operably coupled to receive instructions from the decode queue 318 and decode the fetched instructions. The instructions may be executed by the processor's execution units at a later point in the pipeline. In at least one embodiment, decode logic 330 may be statically divided into decode logic 330A and decode logic 330N. In multi-threaded mode, decode logic 330A may decode instructions read from decode queue 318A, while decode logic 330N may decode instructions read from decode queue 318N. In single-threaded mode, decode logic 330A and decode logic 330N may be unified, and the active thread and the unified decode logic may decode instructions read from the unified decode queue. For example, when the processor 200 is in multi-threaded mode, decode logic 330A may decode instructions associated with the first thread (i.e., instructions received from decode queue 318A) at a rate of N instructions per cycle (N-wide). Decode logic 330N can decode instructions associated with the second thread (i.e., instructions received from decode queue 318N) at a rate of N instructions per cycle (N-wide). When processor 200 operates in single-threaded mode, decode logic 330A and decode logic 330N can be unified so that the unified decode logic can decode instructions associated with the active thread at an increased rate. For example, the unified decode logic can decode instructions at a rate of 2*N instructions per cycle (2*N-wide).

[0054] Because decode logic 330A and 330N are statically partitioned, the first thread and the second thread can run independently of each other when processor 200 is in multithreaded mode. For example, if decode logic 330A receives backpressure from a later stage in its pipeline (e.g., from the rename stage) that prevents the first thread from continuing to run, the second thread can continue to run because both threads have separate data paths in instruction decode and in other stages of processor 200. Decode logic 330A-N is operatively coupled to send decoded instructions to the processor's core 220 for renaming, execution, etc. It should be understood that other pipelines (e.g., fetch, issue, execute, etc.) can be similarly partitioned / combined.

[0055] Rename

[0056] Figure 4 A block diagram of a mid-core 220 of a processor according to aspects and embodiments of the present disclosure is shown. The mid-core 220 may implement the rename, issue, execute, and retire stages of a pipelined processor (eg, IC 100, processor 200). Figure 4 A distributed (eg, multiple issue queues) issue queue topology is shown, however, aspects and implementations of the present disclosure may apply a unified issue queue topology, as described in detail below.

[0057] During the rename 432 phase, instructions may be received from the front end of the processor (e.g., front end 210). During rename 432, the processor assigns physical registers to architectural registers. Architectural registers are registers specified in the instruction set architecture (ISA). During the rename 432 phase, various portions of the processor state may be renamed, with physical copies residing in register files. Registers, flags, predicates, etc. may be renamed during the rename 432 phase. In an illustrative example, the rename 432 phase includes a general purpose register (GPR) file 436 and an advanced SIMD and FP register file 438 for supporting single instruction, multiple data (SIMD) and floating point (FP) operations. In at least one embodiment, the GPR file 502 and the advanced SIMD & FP register file 438 may be statically split. For example, when the processor 200 is operating in multi-threaded mode, a first thread may rename, allocate, etc. a first portion (e.g., half) of the physical registers of the GPR file 436 and the advanced SIMD & FP register file 438, while a second thread may rename, allocate, etc. a second portion (e.g., the other half) of the physical registers of the GPR file 436 and the advanced SIMD & FP register file 438. The write port and the read port of the first portion of the physical registers may be dedicated to the first thread, while the write port and the read port of the second portion of the physical registers may be dedicated to the second thread, thereby avoiding conflicts between the first thread and the second thread. In another example, when the processor 200 is operating in single-threaded mode, the active thread may rename, allocate, etc. each register of the GPR file 436 and the advanced SIMD & FP register file 438.

[0058] In at least one embodiment, the processor may include a speculative rename table (SRT) (not shown) for maintaining speculative mappings from logical registers (e.g., ISA registers) to physical registers. In at least one embodiment, the SRT state may be replicated when operating in multi-threaded mode, and the associated read / write ports may be replicated or statically partitioned per thread. It should be understood that when operating in multi-threaded mode, any structure that references architectural registers may replicate a full set of reference architectural registers for each thread, and the associated read / write ports may be replicated or statically partitioned.

[0059] In at least one embodiment, the processor may include a free list (not shown) for managing the general register file 436 and / or the advanced SIMD & FP register file 438. During the rename 432 phase of the processor, the free list may be used to track the available physical registers in the general register file 436 and / or the advanced SIMD & FP register file. When an instruction requests a register, the processor may check the free list to determine if there are any unused physical registers that the instruction can use. In at least one embodiment, the free list may be statically partitioned per thread.

[0060] The processor's rename 432 stage includes a reorder buffer (ROB) 434. After instructions are renamed, they can be dispatched to the ROB 434 and issue 440 stages. The ROB 434 can track in-flight instructions and decouple instruction execution from instruction retirement, thereby improving execution unit utilization. Furthermore, the ROB 434 can handle exceptions and interrupts. For example, when an exception is thrown, the ROB 434 can roll back uncommitted instructions and restore the architectural state of the processor 200. Furthermore, even if instructions are executed out of order, the ROB 434 can ensure that instructions are retired in program order. Thus, by allowing the processor 200 to execute out of order and commit and retire in order, the ROB 434 can make the architectural state of the processor 200 appear as if instructions were executed in program order. As instructions pass through rename and arrive at dispatch, they can be broken down into smaller units of work that are tracked by the ROB 434. For example, a single store instruction can be broken down into a store address operation and a store data operation. In at least one embodiment, ROB 434 can be statically partitioned on a per-thread basis. For example, as described above, ROB 434 can be statically partitioned using wraparound points.

[0061] In at least one embodiment, the processor 200 may include one or more checkpoints and checkpoint logic for recovering from branch mispredictions, exceptions, interrupts, and other discontinuities associated with out-of-order program execution. Checkpoints may periodically (e.g., dynamically, every fixed number of clock cycles, etc.) capture the architectural state of the processor 200 (e.g., registers, program counter, etc.). When a branch misprediction, exception, interrupt, etc. occurs, the processor 200 may restore the architectural state of the processor 200 to a saved state according to one or more checkpoints and restart execution from the checkpoint, or restart execution from instructions younger than the checkpoint by walking forward from the checkpoint through the rename log in the ROB 434 or edge structure and restoring the architectural state of the younger point. In at least one embodiment, the checkpoints may be partitioned and / or unified according to one or more implementations discussed above.

[0062] Distribution

[0063] After the rename 432 stage, instructions can be dispatched to an issue queue to be issued and then executed. In at least one embodiment, the dispatch stage of the processor can be statically partitioned in a manner similar to that described above with respect to the decode stage. Because the partitioned pipelines operate independently, cross-thread stalls can be avoided and security issues can be prevented, as described above. Furthermore, when operating in single-threaded mode, the dispatch stage can be unified.

[0064] Issue and execute

[0065] The processor 200 includes an issue 440 stage for selecting instructions and issuing them to the appropriate execution unit for execution. The processor 200 includes an issue queue (IQ) for receiving instructions that have been fetched, decoded, and dispatched. The IQ can temporarily store instructions that cannot be executed immediately due to data dependencies or resource unavailability. The main function of the issue queue is to determine which instructions are ready to be executed in the next clock cycle. Aspects and embodiments of the present disclosure are applicable to various topologies. For example, the IQ described herein can be distributed (one IQ per execution unit), centralized (one or more IQs for all execution units), a hybrid approach of the two (e.g., one issue queue serves multiple but not all execution units), or any combination of the above approaches. Therefore, each IQ can serve one or more execution units. For example, the processor 200 may include one or more integer IQs 460A-460N, each of which may service one or more single-cycle or multi-cycle instruction execution pipelines, such as multiplication, division, addition, subtraction, division, logical (AND, OR, XOR, etc.), bit shift, and branch operations, all of which may read from or write to general purpose / integer registers. In at least one embodiment, the processor 200 includes vector / floating point IQs 464A-464N, which may service vector execution units (for executing vector instructions and / or floating point (FP) instructions). The processor 200 may include one or more memory IQs 466A-466N. Each memory IQ 466 may service one or more load execution units and / or one or more load-store execution units.

[0066] In at least one embodiment, one or more of the aforementioned IQs can be vertically partitioned so that each entry in a given issue queue can service a single thread. In an illustrative example, processor 200 may include two or more integer IQs 460, two or more vector / floating-point IQs 464, and two or more memory IQs 466. When processor 200 operates in multi-core mode, with two threads active, integer IQs 460 can be vertically partitioned so that each integer IQ 460 is dedicated to serving a specific thread. In an illustrative example, processor 200 may include integer IQs 460A, 460B, 460C, and 460N. Each entry in integer IQs 460A and 460B can service a first thread of processor 200, while each entry in integer IQs 460C and 460N can service a second thread of processor 200. When processor 200 operates in single-core mode, with one thread active, each entry in integer IQs 460A-460N can service the active thread. In at least one embodiment, vector / floating point IQ 464 and memory IQ 466 may also be vertically partitioned on a per-thread basis.

[0067] In at least one embodiment, one or more of the above-described IQs can be horizontally partitioned so that a given issue queue can service multiple threads. In an illustrative example, processor 200 may include integer IQs 460A, 460B, 460C, 460D, and 460N. When processor 200 operates in multi-core mode with two threads active, each of integer IQs 460A-460N can be horizontally partitioned so that a first portion (e.g., half) of the entries in each of integer IQs 460A-460N serves the first thread, while a second portion (e.g., second half) of the entries in each of integer IQs 460A-460N serves the second thread. In at least one embodiment, more than one picker can each serve an execution unit associated with each of integer IQs 460 and be dedicated per thread. A picker is a hardware component responsible for selecting instructions from the corresponding issue queue for dispatch to the correct execution unit. For example, a first picker dedicated to a first thread can serve a first execution unit associated with integer IQ 460A. A second picker dedicated to a second thread can serve a second execution unit associated with integer IQ 460A. Integer IQs 460B, 460C, 460D, and 460N can be horizontally partitioned in a similar manner. In at least one embodiment, when processor 200 operates in single-core mode with one thread active, each of integer IQs 460A-460N, the corresponding pickers, and the execution units can be dedicated to the active thread.

[0068] In at least one embodiment, the pickers corresponding to the issue queues serving multiple threads can be modulated according to a predefined pattern (e.g., not affected by the dynamic nature of the instructions being executed). In an illustrative example, a first picker and a second picker can retrieve instructions from integer IQ 460A, as described above. The first picker can be dedicated to the first thread and serve the first execution unit, while the second picker can be dedicated to the second thread and serve the second execution unit. Alternatively, in order to maintain thread isolation and avoid security issues associated with the first thread and the second thread sharing resources, the first picker and the second picker that retrieve instructions from integer IQ 460A can be modulated according to a predefined pattern. For example, the first picker can retrieve instructions for the first thread from integer IQ 460A on odd clock cycles, while the second picker can retrieve instructions for the second thread from integer IQ 460A on even clock cycles. Thus, resources can be time-multiplexed so that dynamic instructions do not cause changes in behavior.

[0069] In at least one embodiment, when the processor is operating in multi-core mode, one or more hardware structures and corresponding data paths (e.g., a single type of issue queue and corresponding execution unit) can be dynamically reconfigured to be dedicated to a single thread. For example, a first workload may be executing instructions requiring vector execution resources (e.g., floating-point (FP) instructions) on a first thread of the processor 200, while a second workload may be executing other instructions not requiring vector execution resources on a second thread of the processor 200. Thus, the processor 200 can be reconfigured so that each vector / floating-point IQ 464, fetcher, and corresponding vector execution unit (for FP calculations and vector integer calculations) is dedicated to the first thread to extract increased vector execution performance on behalf of the first workload. Dynamic reconfiguration can be triggered by a timer, detection logic, specific instructions, user input, or other similar mechanisms. In at least one embodiment, when dedicating one or more hardware structures to a single thread is no longer beneficial, the hardware can determine to dynamically reconfigure them back to more than one thread. For example, the dynamic reconfiguration back to more than one thread can be determined by logic that detects that other threads will use the relevant structures or data paths, specific instructions, user input, or a timer.

[0070] As described above, the fetcher can retrieve instructions from the corresponding issue queue for execution on the corresponding execution unit. The execution unit of the processor performs the operation specified by the instruction. In at least one embodiment, the execution units can be statically partitioned per thread. In an illustrative example, the branch execution units can be statically partitioned per thread. When the processor operates in multi-threaded mode, a first set of branch execution units can correspond to a first thread, while a second set of branch execution units can correspond to a second thread. The first set of branch execution units can interface with a branch predictor associated with the first thread, while the second set of branch execution units can interface with a branch predictor associated with the second thread. For example, in the event of a branch misprediction associated with the first thread, the branch execution units from the first set of branch execution units can perform corrective actions (e.g., flushing the pipeline corresponding to the first thread, discarding speculatively executed instructions beyond the misprediction, acquiring the correct branch target, sending an update to the BPU corresponding to the first thread, etc.) without affecting the pipeline corresponding to the second thread. Thus, the branch predictor can receive two mispredictions (a first misprediction associated with the first thread and a second misprediction associated with the second thread) in the same clock cycle and process the simultaneous mispredictions in parallel. The first branch execution unit set corresponding to the first thread and the second branch execution unit set corresponding to the second thread are used herein as examples, not as limitations. Aspects and embodiments of the present disclosure may generally be applied to multi-core processors (and associated branch execution unit sets) having more than two cores, which may be reconfigured as a unified core processor. In at least one embodiment, the execution units may be unified such that each execution unit of the processor serves a unique active thread.

[0071] In order to perform the operations specified by the issued instructions, data may be retrieved from multiple sources (e.g., general register file 436; advanced SIMD & FP register file 438; cache (e.g., L1 data cache 454); bypass networks, etc.). It will be appreciated that when the processor is executing in multi-threaded mode, the execution units and data sources may be statically partitioned on a per-thread basis. For example, a first set of execution units may serve a first thread, and its corresponding first bypass network may also be dedicated to the first thread. A second set of execution units may serve a second thread, and its corresponding second bypass network may also be dedicated to the second thread. Therefore, because the execution units and corresponding bypass networks are statically partitioned on a per-thread basis, a given execution unit may avoid latencies associated with crossing to other bypass networks to retrieve data. Furthermore, when operating in single-threaded mode, the partitioned execution units may be unified to serve a single active thread.

[0072] In at least one embodiment, an IQ pair and corresponding execution unit can be symmetrical. An IQ pair can refer to two IQ units, where, when processor 200 operates in a dual-core configuration (two independent cores), the first IQ in the IQ pair is dedicated to the first core, while the second IQ in the IQ pair is dedicated to the second core. An IQ pair can be symmetrical in that the first IQ and the second IQ have the same number and type of execution units and fetchers. In an illustrative example, integer IQ 460A and integer IQ 460B can each include two ALUs and a branch execution unit. This can ensure that the first and second cores can utilize an equal amount of instruction execution resources. In at least one embodiment, an IQ pair can be asymmetrical. In at least one embodiment, an IQ pair can be extended to an IQ set, for example, in an N-core embodiment when N>2.

[0073] Load-Store

[0074] The processor includes a store buffer 448 for decoupling the execution of store instructions from the commit to memory. The store buffer 448 can save store operations after they have been executed to ensure that the store operations are retired in order. The processor can temporarily record store operations in the store buffer 448 to avoid unnecessary stalls. In some embodiments, the store buffer 448 can be statically partitioned. For example, when the processor 200 operates in multi-threaded mode, the store buffer 448 can be statically partitioned so that a first thread of the processor 200 can record corresponding store operations in a first portion of the store buffer 448, and a second thread can store corresponding store operations in a second portion of the store buffer 448. When the processor 200 operates in single-threaded mode, the store buffer 448 can be unified so that the active thread can use the entire store buffer 448 to record corresponding store operations.

[0075] In at least one embodiment, the processor may include one or more memory IQs 466, as described above. In the illustrative example, a load instruction may be received and stored in a load memory IQ 466A. When conditions are met (e.g., dependencies resolved, execution units available, instruction priority, etc.), the load instruction may be issued for execution. The load instruction may be used to retrieve data from memory (e.g., L1 data cache 454) and store the data in the processor's register file. In at least one embodiment, the processor may determine additional information about the load instruction, such as the instruction source, the load type (signed halfword, unsigned halfword, signed word, unsigned word, byte, doubleword, etc.), the load size (number of bits or bytes to be retrieved from memory), etc. In at least one embodiment, the processor may include an address generation unit (AGU) (not shown) for generating a virtual memory address based on the issued load instruction to access data in a memory cache (e.g., L1 data cache 454) or another memory (e.g., memory subsystem 230).

[0076] In response to the address generation unit generating a virtual memory address corresponding to a transmitted load instruction, a data translation lookaside buffer 452 (DTLB 452) may be queried to determine whether a physical address corresponding to the virtual memory address generated by the address generation unit is stored within DTLB 452. DTLB 452 may include multiple entries, each of which contains a virtual address and a corresponding physical address translation. When a data access occurs (e.g., due to a load instruction), the processor first queries DTLB 452 to determine whether the address translation is readily available. In response to determining that the translation is in DTLB 452 (DTLB hit), the physical address may be retrieved from DTLB 452, and execution of the load instruction may continue. In response to determining that the translation is not in DTLB 452 (DTLB miss), a page table walk is initiated to locate the corresponding address translation in the page table (not shown) and update DTLB 452 with the corresponding address translation. In at least one embodiment, DTLB 452 may be partitioned per thread according to one or more of the partitioning methods described above.

[0077] The processor includes an L1 data cache 454. The L1 data cache 454 can store recently accessed data. The memory address generated from the load instruction can be checked within the L1 data cache 454 to determine whether the requested data is stored in the L1 data cache 454. If the data is stored in the L1 data cache 454, a cache hit occurs, and the data can be retrieved from the data cache 454. If the data is not stored in the L1 data cache 454, a cache miss occurs, and the data can be retrieved from a higher level of memory (e.g., memory in the memory subsystem). In some embodiments, the L1 data cache 454 can be partitioned per thread. In at least one embodiment, the partitioned L1 data cache 454 can arbitrate access to the memory subsystem on a per-thread basis.

[0078] The store address (STA) instruction can follow a path similar to the load instruction. For example, the AGU can generate a virtual memory address for accessing data in the memory cache, can query the DTLB 452 to determine whether the physical address corresponding to the virtual memory address generated by the AGU is stored in the DTLB 452, and can perform arbitration on the entries entering the load-store pipeline. After the arbitration enters the load-store pipeline, an entry can be allocated in the store buffer 448 to track the address of the store instruction currently being processed by the load-store pipeline. In at least one embodiment, the processor can determine which entry to write to the store buffer 448 based on the thread ID of the store instruction, wherein the entries are partitioned per thread. In at least one embodiment, in response to the memory address of the store instruction being written to the store buffer 448, the store instruction can be parsed. In response to the store instruction being parsed, a notification can be sent to the ROB 434 to remove the STA instruction from the ROB 434.

[0079] A store data (STD) instruction may cause the storage data to be calculated according to the store instruction and stored in a storage buffer 448. The storage buffer 448 may hold the data until the appropriate time to write the data to a memory (e.g., a memory subsystem). The STD instruction may be written to the storage buffer 448 before or after the corresponding STA instruction is written to the storage buffer 448 with the same SID as the corresponding STA instruction. For a given storage buffer 448 entry, when data associated with the corresponding STD instruction is received, the given storage buffer 448 in the storage buffer 448 may be deallocated. In addition, the corresponding data stored in the storage buffer 448 may be transferred to a write-combining buffer (WCB), which may combine writes to data lines before being submitted and written to the memory. In at least one embodiment, the pipeline and hardware structure associated with the storage operation may be statically partitioned on a per-thread basis according to one or more of the above methods.

[0080] In at least one embodiment, the load-store pipeline may include a DCache Miss Tracker (DCMT) (not shown) along the miss path of the load-store pipeline. The DCMT is a hardware structure that tracks outstanding L2 memory (e.g., within the memory subsystem) read requests that have missed the L1. In at least one embodiment, the DCMT may be statically split on a per-thread basis according to one or more of the methods described above.

[0081] The mid-core 220 includes a load buffer 444 within the load-store pipeline. The purpose of load buffer 444 is to detect memory ordering violations and ensure consistency. In at least one embodiment, load buffer 444 can prevent read-after-read (RAR) data conflicts / dependencies, with logic referred to as a completion load buffer (FLB). For example, a RAR data dependency can occur when a first load instruction causes data to be read from a memory location (e.g., a register), while a subsequent load instruction causes the same data to be read from the same memory location (e.g., the same register). This situation can result in a data hazard, for example, if the subsequent load instruction causes the data to be read before it is available or the data has been modified. To prevent RAR data hazards, load buffer 444 includes FLB logic that can track pending load instructions that do not yet have a calculated address. For example, the first load instruction may not yet have a calculated address. The subsequent load instruction may be stored in load buffer 444, suspending the calculation of the first load address. When the first load address is calculated, it is compared with the address of the subsequent load instruction stored in load buffer 444. Load instructions stored in the load buffer 444 with calculated addresses matching the first load address may be discarded to prevent RAR data dependency risks.

[0082] In at least one embodiment, load buffer 444 may utilize FLB logic to prevent read-after-write (RAW) data hazards. For example, a RAW hazard violation may occur when a store instruction causes data to be written to a memory location (e.g., a register) and a subsequent load instruction causes data to be read from the same memory location (e.g., the same register). This situation may result in a data hazard violation if the subsequent load operation reads data that will be stored by the write operation. For example, a RAW data hazard violation may occur if the subsequent load instruction reads from a memory location before the write instruction has written the data to that memory location. To prevent RAW data hazard violations, load buffer 444 includes FLB logic that can track completed load instructions that are younger than one or more store instructions with addresses that have not yet been calculated. For example, a first store instruction may not yet have a calculated address. Subsequent load instructions may be stored in load buffer 444, suspending the calculation of the store address. When the store address is calculated, the store address is compared with the address of the subsequent load instruction stored in load buffer 444. Load instructions stored in the load buffer 444 whose calculated addresses match the addresses of store instructions can be discarded to prevent read-after-write data dependency risks. In at least one embodiment, the load buffer 444 and associated structures (e.g., memory disambiguation buffers, FLBs, etc.) can be statically split on a per-thread basis according to one or more of the methods described above.

[0083] In at least one embodiment, the processor may include one or more prefetchers (not shown). A prefetcher is a structure that generates predictions of data requests and retrieves the data from the memory subsystem before the processor requests the data. One or more prefetchers can speculatively issue requests to the memory subsystem based on the predictions. The prefetchers can generate predictions using principles such as spatial locality (e.g., the tendency of nearby data to be accessed together or in a pattern), temporal locality (e.g., predictions of future iterations of a loop), etc. In at least one embodiment, one or more prefetchers can be statically partitioned per core according to one or more of the methods described above.

[0084] quit

[0085] In at least one embodiment, the processor may include a retire (also referred to herein as a "commit") stage (not shown) for updating the processor's architectural state to reflect the effects of the executed instructions. As described above, instructions may be allocated in the reorder buffer (ROB) 434 in program order and executed out of order. In at least one embodiment, instruction groups may be retired in program order. For example, resources associated with the oldest instruction group may be freed for use by the processor and for processing newer instructions. In at least one embodiment, the engine may identify the oldest entry in the ROB 434 to be retired. Thus, by allowing instructions to execute out of order and commit / retire in order, the ROB 434 may make the processor's architectural state appear as if the instructions were executed in program order. In at least one embodiment, the ROB 434 may be statically partitioned per core according to one or more of the methods described above.

[0086] In at least one embodiment, instructions can be retired in a time-multiplexed manner by alternating instruction retirement on a per-thread basis. For example, when the processor is operating in multi-threaded mode, N instructions associated with a first thread can be retired in a first clock cycle, and N instructions associated with a second thread can be retired in a second clock cycle. Instructions can continue to be retired in this alternating manner.

[0087] In at least one embodiment, the processor may include one or more checkpoints and checkpoint logic for recovering from branch mispredictions, exceptions, interrupts, and other discontinuities associated with out-of-order program execution, as described above. Checkpoints may capture the processor's architectural state (e.g., registers, program counter, etc.) periodically (e.g., dynamically, every fixed number of clock cycles, etc.). When a branch misprediction, exception, interrupt, etc. occurs, the processor may restore the architectural state to a saved state based on the one or more checkpoints and restart execution from the checkpoint. In at least one embodiment, the checkpoints may be statically partitioned per thread. For example, when the processor is operating in multi-threaded mode, a first core and a second core may independently have branch mispredictions and be refreshed and restored to corresponding checkpoints simultaneously. Static partitioning on a per-thread basis may help prevent any one thread from hogging all resources, starving another thread, and may generally avoid unfair (e.g., unequal) resource allocation.

[0088] Memory subsystem

[0089] Figure 51 is a block diagram of a memory subsystem 230 of a processor according to aspects and embodiments of the present disclosure. The memory subsystem is operatively coupled to the instruction fetch unit 310 (IFU 310) of the front end 210 and the mid-core 220. The IFU 310 includes an L1 instruction cache 312 and an instruction translation lookaside buffer 314 (ITLB 314), as described above with respect to FIG. Figure 3 The core 220 includes an L1 data cache 454 and a data translation lookaside buffer 452 (DTLB 452), as described above with respect to Figure 4 As stated.

[0090] In at least one embodiment, the memory subsystem 230 includes an L2 cache 562 and a unified L2 secondary translation lookaside buffer 564 (unified STLB 564). The unified STLB 564 can be shared between data address translation (e.g., DTLB 452) and instruction address translation (e.g., ITLB 314). If the processor does not find an entry in either DTLB 452 or ITLB 314 (a "miss"), the processor can initiate a request to the unified STLB 564 to determine whether the requested translation exists in the unified STLB 564. If no entry is found in the unified STLB 564, a page walk can be performed to fill the entry. In at least one embodiment, a page walk unit can handle page walks and can be statically partitioned and / or combined according to one or more of the above methods. The L2 cache 562 can be shared between data (e.g., L1 data cache 454) and instructions (e.g., L1 instruction cache 312). If the processor does miss in the data cache 454 or the L1 instruction cache 312, the processor may initiate a request to the L2 cache 562 to determine whether the requested data or instruction exists in the L2 cache 562. If no entry is found in the L2 cache 562, the cache line request may be sent to a system external to the memory subsystem 230.

[0091] In at least one embodiment, when the processor operates with multiple cores, port access to dedicated interfaces (e.g., buses) between the memory subsystem 230 and the IFU 310, and between the memory subsystem 230 and the core 220, can be arbitrated between the cores (e.g., round-robin arbitration, etc.). The L1 instruction cache 312, ITLB 314, and DTLB 452, as well as the L1 data cache 454, can arbitrate port access to the various interfaces of the memory subsystem 230. In at least one embodiment, the processor can include multiple interfaces dedicated to corresponding cores. It should be understood that arbitration for access to the memory subsystem 230 can include other known arbitration methods, such as priority-based arbitration (e.g., a priority assigned to a thread based on thread importance, thread type, application requirements, etc.) or other predefined arbitration strategies.

[0092] Refactoring

[0093] Figure 6 A flowchart of an example method 600 for dynamically reconfiguring a processor from multiple cores to a unified core according to aspects and embodiments of the present disclosure is shown. Although shown in a particular sequence or order, the order of operations may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated operations may be performed in a different order, and some operations may be performed in parallel. Furthermore, one or more operations may be omitted in various embodiments. Therefore, not all operations are required in every embodiment.

[0094] In operation 602 of method 600, a first thread is executed in a first pipeline of a first core of an integrated circuit (IC). The first core includes a first hardware architecture set. In at least one embodiment, the first hardware architecture set may include the above-mentioned Figure 2 、 Figure 3 、 Figure 4 and Figure 5 For example, the first hardware structure set may include one or more buffers (e.g., Figure 3 434), a reorder buffer 434 (ROB 434), a store buffer 448 (SB 448), a data translation lookaside buffer 452 (DTLB 452), etc.); caches (e.g., an L1 instruction cache 312, an L1 data cache 454, an L2 cache 562, etc.); a branch predictor; queues associated with various stages of the first pipeline (e.g., a decode queue 318); register files (e.g., a general register file 436, an advanced SIMD&FP register file 438, etc.); execution units (e.g., an arithmetic logic unit (ALU), a load / store unit, a vector processing (VX) unit, a branch execution unit, etc.); and the like.

[0095] In operation 604, the second thread is executed in a second pipeline of a second core of the IC. The second core includes a second hardware architecture set. In at least one embodiment, the second hardware architecture set may include the above-mentioned Figure 2 、 Figure 3 、 Figure 4 and Figure 5 The hardware structure described is separate from the first hardware structure set. For example, the first hardware structure set may include one or more buffers (e.g., Figure 3 434, SB 448, DTLB 452, etc.); caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.); branch predictor; queues (e.g., decode queue 318); register files (e.g., general register file 436, advanced SIMD & FP register file 438, etc.); execution units (e.g., arithmetic logic unit (ALU), load / store unit, vector processing (VX) unit, branch execution unit, etc.); and the like.

[0096] In at least one embodiment, a subset of the first hardware fabric set and a subset of the second hardware fabric set can share read access to a subset of the hardware fabric that is statically partitioned between the first core and the second core. For example, one or more caches provided on the IC (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.) can be provided as associative caches that are statically partitioned into subsets of cache lines or cache ways, where each partition serves a respective core of the IC, as described above. In another example, static partitioning of the hardware fabric subsets between the first core and the second core can be managed by pointers and wraparound points or wraparound pointers, as described above.

[0097] In operation 606, operations 608 and 610 are performed in response to a command to operate the IC having a unified core. In at least one embodiment, the command to operate the IC having a unified core is issued in response to determining that the second thread has been in an inactive state for more than a threshold number of clock cycles. In at least one embodiment, the threshold number of clock cycles can be defined by the designer of the processor. For example, the designer can define the threshold number of clock cycles as 50 clock cycles before switching between processor modes. In at least one embodiment, the threshold number of clock cycles can be a configurable parameter. For example, the threshold number of clock cycles can be configured by system software in the silicon to define parameters of a hardware component that dictates the threshold number of clock cycles. In at least one embodiment, the threshold number of clock cycles can be configured via basic input / output system (BIOS) settings, unified extensible firmware interface (UEFI) settings, device drivers, etc. The inactive state indicates that the core is not currently executing instructions or performing a computing task. In at least one embodiment, the second core may enter an inactive state in response to receiving an instruction (e.g., a wait for interrupt (WFI) instruction or a pause instruction) from system software of the IC (e.g., an operating system (OS), a virtual machine, a hypervisor, firmware, etc.) indicating that the second thread is transitioning to an inactive state. The instruction instructs the core (e.g., the second core) to suspend execution until the core receives an interrupt signal from the system software. When the interrupt signal is received from a hardware component (e.g., an interrupt controller), the core may resume executing instructions (also referred to herein as "waking up").

[0098] In at least one embodiment, the command may be received from system software of the processor. In at least one embodiment, the command may be received from firmware such as a basic input / output system (BIOS). In at least one embodiment, the command may be received from an application or other software source. In at least one embodiment, a hardware component may detect a condition that causes the processor to be reconfigured into a unified core. For example, the hardware component may detect that the second core has been inactive for a threshold number of clock cycles, thereby causing the processor to be reconfigured into a unified core, as described above.

[0099] In at least one embodiment, in response to determining that the first core has reached an interruptible point, a command to operate the IC having the unified core is issued. In at least one embodiment, the interruptible point may indicate that the first core is in a state that allows pipeline and structural reconfiguration. The interruptible point is a specific point in the execution of an instruction sequence at which the first core can be interrupted while preserving the program state of the first core.

[0100] In some embodiments, before the first core and the second core are unified, the first pipeline and / or the second pipeline can be flushed. For example, to flush the first pipeline, instructions currently in the first pipeline can be flushed. To flush the instructions currently in the first pipeline, instructions in various stages of the first pipeline can be removed or invalidated to prevent the execution of instructions that have been fetched and only partially executed. In at least one embodiment, the flush can be initiated by the retirement unit to ensure that instructions that have not yet been committed or retired are flushed from the first pipeline. In at least one embodiment, a subset of the first set of data structures can be flushed. For example, the out-of-order execution structure (e.g., the reorder buffer 434) can be flushed to discard any instructions from the first pipeline that have been flushed. In at least one embodiment, the BTB and register files (e.g., the general register file 436, the advanced SIMD & FP register file 438) can be flushed. In at least one embodiment, data stored in another subset of the first set of data structures can be retained (e.g., not flushed). For example, the processor may avoid flushing caches (e.g., L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.) and translation lookaside buffers (e.g., ITLB 314, DTLB 452, unified STLB 564, etc.). In at least one embodiment, the register file and rename state, microarchitectural state, and / or architectural state may be saved before flushing to ensure that the state can be restored before resuming execution of the first thread.

[0101] At operation 608, the first core and the second core are unified to obtain a unified core. The first pipeline and the second pipeline are unified to obtain a unified pipeline, and the first hardware architecture set and the second hardware architecture set are unified to obtain a unified hardware architecture set. In at least one embodiment, to unify the first hardware architecture set and the second hardware architecture set, the IC can be reconfigured to allow the unified core to assign entries to the first hardware architecture set and the second hardware architecture set. The first hardware architecture set and the second hardware architecture set can be unified according to one or more of the above methods.

[0102] In at least one embodiment, the stages of the first pipeline and the second pipeline can be unified to obtain a unified pipeline in which the unified core can operate. Thus, the unified pipeline can execute active threads with increased bandwidth compared to the first pipeline executing the first thread and the second pipeline executing the second thread. For example, before being converted to a unified core, the IC can operate the first pipeline in the first core of the IC in parallel (referred to as N-wide) with a maximum bandwidth of N instructions per clock cycle, and can operate the N-wide second pipeline in the second core of the IC. The pipeline stages (e.g., fetch, decode, rename, etc.) of the first core and the second core can be unified so that the IC can operate the unified pipeline in the unified core with the full width of the IC. For example, the N-wide pipelines of the first core and the second core can be unified into a unified pipeline so that the IC can operate a 2N-wide unified pipeline in the unified core.

[0103] In at least one embodiment, the method further includes: saving the architectural state, microarchitectural state, and / or rename state (collectively referred to herein as "state") of the first core and the second core to an edge structure of the IC, and restoring the state of the first core to the unified core in response to unifying the first core and the second core. In an illustrative example, the rename state of the first core and the second core can be saved and restored. The rename state or renamed architectural state can refer to values stored in physical registers (e.g., general register file 436, advanced SIMD & FP register file 438, control registers, special registers, etc.) assigned to a particular core. The physical registers assigned to store the rename state of the inactive threads of the second core can be released to allow active threads (e.g., threads operating on the unified core) to access physical registers previously used by the inactive threads of the second core. To allow full utilization of the physical registers of the IC, the values associated with the physical registers of the inactive thread assigned to the idle second core (referred to herein as "rename state") can be saved to a side structure (e.g., a dedicated storage element or a dedicated register for storing the rename state) and restored when the inactive thread wakes up at a later point. In at least one embodiment, the dedicated register for storing the saved rename state can be accessed via a dedicated register access bus.

[0104] In response to unifying the first core with the second core, the renaming state of the first core may be restored to the unified core to execute active threads on the unified core. It should be understood that the saving and restoring of the renaming state may be implemented by processing logic, which may include hardware (e.g., a state machine), software (e.g., instructions executed on an IC), firmware, or a combination thereof.

[0105] At operation 610 , a single thread (eg, a first thread) is executed in a unified pipeline of a unified core using a unified set of hardware structures.

[0106] Figure 7 A flowchart of an example method 700 for dynamically reconfiguring a processor from a unified core to multiple cores according to aspects and embodiments of the present disclosure is shown. Although shown in a particular sequence or order, the order of operations may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated operations may be performed in a different order, and some operations may be performed in parallel. Furthermore, one or more operations may be omitted in various embodiments. Therefore, not all operations are required in every embodiment.

[0107] In operation 702 of method 700, a first pipeline is provided on an integrated circuit (IC) (e.g., Figure 1A and Figure 1B The first core includes a first hardware structure set. In at least one embodiment, the first hardware structure set may include the above Figure 2 、 Figure 3 、 Figure 4 and Figure 5 For example, the first hardware structure set may include one or more buffers (e.g., Figure 3 434), a reorder buffer 434 (ROB 434), a store buffer 448 (SB 448), a data translation lookaside buffer 452 (DTLB 452), etc.); caches (e.g., an L1 instruction cache 312, an L1 data cache 454, an L2 cache 562, etc.); a branch predictor; queues associated with various stages of the first pipeline (e.g., a decode queue 318); register files (e.g., a general register file 436, an advanced SIMD&FP register file 438, etc.); execution units (e.g., an arithmetic logic unit (ALU), a load / store unit, a vector processing (VX) unit, a branch execution unit, etc.); and the like.

[0108] In operation 704, operations 706, 708, and 710 are performed in response to a command to operate an IC having multiple cores. In at least one embodiment, the command to operate an IC having multiple cores is issued in response to determining that the second thread is ready to execute on the IC. In at least one embodiment, the second thread is ready to execute on the IC in response to receiving an interrupt from a hardware component of the IC (e.g., an interrupt controller). For example, the second thread may be in an inactive state due to previously receiving an instruction from the operating system (such as a wait for interrupt (WFI) instruction or a pause instruction). The second thread may subsequently receive an interrupt from the operating system, causing the second thread to resume executing instructions on the IC (e.g., "wake up").

[0109] In at least one embodiment, a command to operate an IC having multiple cores is issued in response to determining that a first core (e.g., a unified core) has reached an interruptible point. The interruptible point is a specific point in the execution of a first thread at which the first core can be interrupted while preserving the program state of the first core.

[0110] In some embodiments, before reconfiguring the IC to operate with multiple cores, the first pipeline is flushed. To flush the first pipeline, instructions currently in the first pipeline may be flushed. To flush the instructions currently in the first pipeline, instructions in various states of the first pipeline may be removed or invalidated to prevent execution of instructions that have been fetched and only partially executed. In at least one embodiment, the flush may be initiated by a retirement unit to ensure that instructions that have not yet been committed or retired are flushed from the first pipeline. In at least one embodiment, a subset of the first set of data structures may be flushed. For example, the out-of-order execution structures (e.g., the reorder buffer 434) may be flushed to discard any instructions from the first pipeline that have been flushed. In at least one embodiment, the branch target buffer and register files (e.g., the general register file 436, the advanced SIMD & FP register file 438) may be flushed. In at least one embodiment, data stored in another subset of the first set of data structures may be retained (e.g., not flushed). For example, the processor may avoid flushing caches (eg, L1 instruction cache 312, L1 data cache 454, L2 cache 562, etc.) and translation lookaside buffers (eg, ITLB 314, DTLB 452, unified STLB 564, etc.).

[0111] At operation 706, a first core (e.g., unified core 110C) is partitioned to obtain a second core (e.g., core 110A) and a third core (e.g., core 110B). To partition the first core, the first pipeline can be partitioned to obtain a second pipeline and a third pipeline, and the first hardware resource set can be partitioned to obtain a second hardware resource set and a third hardware resource set. In at least one embodiment, to partition the first hardware structure set with the second hardware structure set, the IC can be reconfigured to prevent the second core from being assigned to the third hardware structure set and to prevent the third core from being assigned to the second hardware structure set. Thus, the second core and the third core can have exclusive access to the second hardware structure set and the third hardware structure set, respectively. Partitioning of the hardware structure and pipelines can be performed according to one or more of the above methods.

[0112] In at least one embodiment, the stages of a first pipeline can be partitioned to obtain a second pipeline and a third pipeline, and the second core and the third core can operate within the second pipeline and the third pipeline, respectively. For example, before converting to a multi-core, the IC can operate a first pipeline in a first core (e.g., a unified core) of the IC in parallel at a maximum bandwidth of 2N instructions per clock cycle (e.g., 2N wide). The pipeline stages (e.g., fetch, decode, rename, etc.) of the unified core can be partitioned so that the IC can operate multiple independent pipelines in parallel. For example, the 2N-wide pipeline stages of the unified core can be partitioned so that the IC can independently execute threads on two separate N-wide pipelines.

[0113] In some embodiments, the IC can be partitioned into a multi-core configuration with more than two cores. For example, the stages of a first pipeline can be partitioned to obtain four separate pipelines, and the four cores can each operate within the four separate pipelines in a quad-core configuration. The pipeline stages of a unified core can be partitioned so that the IC can operate four independent pipelines in parallel. For example, the N-wide pipeline stages of a unified core can be partitioned so that the IC can independently execute threads on four separate N / 4-wide pipelines.

[0114] In at least one embodiment, the method further includes saving the architectural state, microarchitectural state, and / or renaming state of the first core to an edge structure of the IC, and restoring the renaming state of the first core to the second core in response to partitioning the first core. In some embodiments, the state can be saved before reconfiguring into multiple cores and restored after reconfiguring into multiple cores. For example, values associated with physical registers of the first core (referred to herein as "state") can be saved to an edge structure (e.g., a dedicated storage element or a dedicated register for storing renaming state) and restored to the second core after reconfiguring from a unified core into multiple cores. In some embodiments, the architectural state, microarchitectural state, and / or renaming state associated with the second thread can be restored to a third core after reconfiguring from a unified core into multiple cores. In at least one embodiment, the architectural state, microarchitectural state, and / or renaming state of the second thread may have previously been saved to an edge structure in response to entering an inactive state. It should be understood that saving and restoring the renaming state can be implemented by processing logic, which can include hardware (e.g., a state machine), software (e.g., instructions executed on the IC), firmware, or a combination thereof.

[0115] At operation 708 , the first thread is executed on a second pipeline of a second core of the IC, the second core including a second set of hardware structures.

[0116] At operation 710 , a second thread is executed on a third pipeline of a third core of an IC, the third core including a third set of hardware structures.

[0117] Figure 8 is a block diagram illustrating an exemplary computer system 800 according to aspects and embodiments of the present disclosure. Figure 1A and Figure 1B The described IC 100 can operate within a computer system 800. The computer system 800 can operate in the capacity of a server or endpoint machine in an endpoint-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a television, a personal computer (PC), a tablet, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by the machine. Furthermore, while a single machine is shown, the term "machine" should also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0118] The example computer system 800 includes a processing device (processor) 802, a main memory 804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM), double data rate (DDRSDRAM) or DRAM (RDRAM), etc.), a static memory 806 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 818, which communicate with each other via a bus 840. In at least one embodiment, the processor 802 may be Figure 1A and Figure 1B IC 100 or Figure 2 One of the processors 200.

[0119] Processor (processing device) 802 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, processor 802 can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets or a processor that implements a combination of instruction sets. Processor 802 can also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. Processor 802 is configured to execute instructions 826 to perform the operations discussed herein.

[0120] The computer system 800 may also include a network interface device 808. The computer system 800 may also include a video display unit 810 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an input device 812 (e.g., a keyboard, an alphanumeric keyboard, a motion sensing input device, a touch screen), a cursor control device 814 (e.g., a mouse), and a signal generating device 818 (e.g., a speaker).

[0121] The data storage device 816 may include a non-transitory machine-readable storage medium 824 (also referred to as a non-transitory computer-readable storage medium) on which is stored one or more sets of instructions 826 that embody one or more methods or functions described herein. During execution of the instructions by the computer system 800, the instructions may also reside, completely or at least partially, in the main memory 804 and / or the processor 802, which also constitute machine-readable storage media. Instructions may also be sent or received over the network 830 via the network interface device 808.

[0122] In one embodiment, the instructions 826 include instructions for reconfiguring a unified core processor into a multi-core processor or reconfiguring a multi-core processor into a unified core processor. Although the computer-readable storage medium 824 (machine-readable storage medium) is shown as a single medium in an exemplary embodiment, the terms "computer-readable storage medium" and "machine-readable storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more instruction sets. The terms "computer-readable storage medium" and "machine-readable storage medium" should also be understood to include any medium that can store, encode, or carry an instruction set for execution by a machine and cause the machine to perform any one or more methods of the present disclosure. Therefore, the terms "computer-readable storage medium" and "machine-readable storage medium" should be understood to include, but are not limited to, solid-state memory, optical media, and magnetic media.

[0123] Reference throughout this specification to "one embodiment," "an example," "an embodiment," or "an example" means that a particular feature, structure, or characteristic described in connection with the embodiment and / or example is included in at least one embodiment and / or example. Thus, various appearances of the phrases "in one embodiment" or "in an example" in this specification may, but do not necessarily, refer to the same embodiment, depending on the context. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0124] When the terms "includes," "comprising," "having," "containing," variations thereof, and other similar words are used in the detailed description or claims, these terms are intended to be inclusive in a manner similar to the term "comprising" as an open transition word and do not exclude any additional or other elements.

[0125] As used in this application, the terms "component," "module," "system," and the like are generally intended to refer to a computer-related entity, which can be hardware (e.g., circuitry), software, a combination of hardware and software, or an entity associated with an operating machine having one or more specific functions. For example, a component can be, but is not limited to, a process, a processor, an object, an executable file, an execution thread, a program, and / or a computer running on a processor (e.g., a digital signal processor). As an example, both an application running on a controller and the controller can be components. One or more components can reside in a process and / or execution thread, and a component can be located on one computer and / or distributed between two or more computers. In addition, a "device" can take the form of specially designed hardware; general-purpose hardware specialized by executing software thereon, the software enabling the hardware to perform specific functions (e.g., generating points of interest and / or descriptors); software on a computer-readable medium; or a combination thereof.

[0126] The above-mentioned systems, circuits, modules, etc. have been described with respect to the interaction between several components and / or blocks. It will be understood that such systems, circuits, components, blocks, etc. may include these components or specified sub-components, some of the specified components or sub-components and / or additional components, and in various permutations and combinations of the foregoing. Sub-components may also be implemented as components that are communicatively coupled to other components, rather than being included within a parent component (layered). In addition, it should be noted that one or more components may be combined into a single component that provides aggregate functionality, or may be divided into several separate sub-components, and any one or more intermediate layers (e.g., management layers) may be provided to communicatively couple to such sub-components to provide integrated functionality. Any component described herein may also interact with one or more other components not specifically described herein but known to those skilled in the art.

[0127] In addition, the words "example" or "exemplary" as used herein are meant to serve as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as superior or advantageous over other aspects or designs. On the contrary, the use of the words "example" or "exemplary" is intended to present concepts in a concrete way. As used in this application, the term "or" means an inclusive "or" rather than an exclusive "or." That is, unless otherwise specified or clear from the context, "X employs A or B" means any natural inclusive arrangement. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied in any of the above cases. In addition, the articles "a" and "an" used in this application and the appended claims should generally be interpreted as "one or more" unless otherwise specified or clear from the context to be in the singular.

Claims

1. A method for operating an integrated circuit (IC), the method comprising: executing a first thread in a first pipeline of a first core of the IC, the first core including a first set of hardware structures; executing a second thread in a second pipeline of a second core of the IC, the second core including a second set of hardware structures; as well as In response to a command to operate the IC having the unified core: Unifying the first core with the second core to obtain the unified core, wherein unifying the first core with the second core comprises at least one of: unifying the first pipeline with the second pipeline to obtain a unified pipeline or unifying the first hardware fabric set with the second hardware fabric set to obtain a unified hardware fabric set; and A single thread is executed in the unified pipeline of the unified core using the unified set of hardware structures.

2. The method according to claim 1, further comprising: In response to determining that the second thread has been inactive for more than a threshold number of clock cycles, issuing the command to operate the IC having the unified core. The method of claim 2 , wherein the threshold number of clock cycles is a configurable parameter. 4 . The method of claim 2 , wherein the second core enters the inactive state in response to receiving an instruction indicating that the second thread is transitioning to the inactive state.

5. The method according to claim 1, further comprising: saving at least one of an architectural state or a microarchitectural state of the first core to an edge structure of the IC; as well as In response to unifying the first core with the second core, at least one of the architectural state or the microarchitectural state of the first core is restored to the unified core.

6. The method of claim 1 , wherein unifying the first hardware structure set with the second hardware structure set to obtain the unified hardware structure set comprises: The IC is reconfigured to allow the unified core to allocate entries to the first set of hardware fabrics and the second set of hardware fabrics.

7. The method of claim 1 , wherein unifying the first hardware structure set with the second hardware structure set to obtain the unified hardware structure set comprises: Wrap pointers associated with the first hardware fabric set and the second hardware fabric set are modified to enable the first thread to be assigned to each entry of the unified hardware fabric set.

8. The method according to claim 1, further comprising: In response to the command to operate the IC having the unified core, the first pipeline is refreshed. 9 . The method of claim 8 , wherein flushing the first pipeline comprises at least one of flushing instructions currently present within the first pipeline or flushing one or more hardware structures in the first set of hardware structures.

10. The method of claim 1 , wherein the first set of hardware structures and the second set of hardware structures each include one or more caches, a translation lookaside buffer (TLB), a register file, queues associated with stages of the first pipeline and the second pipeline, respectively, a branch predictor, a branch target buffer, an execution unit, a prefetcher, and a scheduler.

11. A processor comprising at least a first core and a second core among a plurality of cores, wherein the first core corresponds to a first pipeline and a first hardware structure set, and the second core corresponds to a second pipeline and a second hardware structure set, wherein the processor is configured to: executing a first thread in the first pipeline of the first core; executing a second thread in the second pipeline of the second core; In response to a command to operate the processor having a unified core, unifying the first core with the second core to obtain the unified core, wherein the unified core includes at least one of a unified pipeline or a unified hardware structure set, the unified pipeline including the first pipeline and the second pipeline, and the unified hardware structure set including the first hardware structure set and the second hardware structure set; and A single thread is executed in the unified pipeline of the unified core using the unified set of hardware structures.

12. The processor of claim 11, wherein the command to operate the processor having the unified core is issued in response to determining that the second thread has been inactive for more than a threshold number of clock cycles.

13. The processor of claim 12, wherein the threshold number of clock cycles is a configurable parameter.

14. The processor of claim 12, wherein the second core enters the inactive state in response to receiving an instruction indicating that the second thread is transitioning to the inactive state.

15. The processor of claim 11, wherein the processor is further configured to: saving at least one of an architectural state or a microarchitectural state of the first core into an edge structure of the processor; and In response to unification of the first core and the second core, at least one of the architectural state or the microarchitectural state of the first core is restored to the unified core.

16. The processor of claim 11, wherein unifying the first core with the second core comprises: The processor is reconfigured to allow the unified core to allocate entries to the first set of hardware fabrics and the second set of hardware fabrics.

17. The processor of claim 11, wherein unifying the first core with the second core comprises: Wrap pointers associated with the first hardware fabric set and the second hardware fabric set are modified to enable the first thread to be assigned to each entry of the unified hardware fabric set.

18. The processor of claim 11, wherein in response to a command to operate the processor having a unified core, the processor is further configured to flush the first pipeline.

19. The processor of claim 18, wherein to flush the first pipeline, the processor is configured to flush at least one of an instruction currently present in the first pipeline or one or more hardware structures in the first set of hardware structures.

20. The processor of claim 11, wherein the first hardware structure set and the second hardware structure set each include one or more caches, a translation lookaside buffer (TLB), a register file, queues associated with stages of the first pipeline and the second pipeline, respectively, a branch predictor, a branch target buffer, an execution unit, a prefetcher, and a scheduler.

21. A system comprising: Memory subsystem; as well as a processing device coupled to the memory subsystem, wherein the processing device is configured to: executing a first thread in a first pipeline of a first core of the processing device, the first core including a first set of hardware structures; executing a second thread in a second pipeline of a second core of the processing device, the second core including a second set of hardware structures; and In response to a command to operate the processing device having the unified core: unifying the first core with the second core to obtain the unified core, wherein, in order to unify the first core with the second core, the processing device is configured to at least one of: unify the first pipeline with the second pipeline to obtain a unified pipeline or unify the first hardware structure set with the second hardware structure set to obtain a unified hardware structure set; and A single thread is executed in the unified pipeline of the unified core using the unified set of hardware structures.

Images