Microprocessor and branch processing method

Abstract

The present application relates to a microprocessor and a branch handling method. In one embodiment, a branch handling method includes: receiving information from at least two branch execution units; writing two updates to corresponding first and second write queues in each clock cycle based on the information; and writing up to two updates from the first write queues to multiple tables of a first predictor in each clock cycle, and writing a single update for a single clock cycle in the event of an expected write conflict, wherein the first predictor includes a single write or read / write port.

Description

Technical Field

[0001] The present invention relates generally to microprocessors and, more particularly, to branch prediction in microprocessors. Background Art

[0002] Microprocessors today operate using a pipeline processing scheme whereby programmed instructions are broken down into steps that are executed concurrently in multiple stages of the pipeline. Instructions typically (e.g., 10-20% of programmed code) include branch instructions or simple branches, including unconditional branches (e.g., branches that are always taken) and conditional branches (e.g., branches that are taken or not taken based on the evaluation of a specified condition). Whether a conditional jump is taken or not is generally not known with certainty until the condition is calculated and the conditional jump passes through the execution stage in the instruction pipeline, which can cause delays in fetching the next instruction. Branch predictors have been developed to attempt to guess at the front end of the pipeline which direction a conditional branch will go and to which target address, and in doing so improve the flow of instructions throughout the pipeline.

[0003] If there is a bottleneck in the rest of the pipeline, there is no real value in improving the instruction flow in the entire pipeline through branch prediction. Therefore, microprocessors have been developed to decode and execute two branches per clock cycle. In the decode stage, for instructions that are not predicted by the front-end predictor (e.g., by a branch target address cache or BTAC), or even for those that are predicted, the instructions are formatted for each branch and the target address of the displacement branch is checked by adder logic, which increases cost and complexity. Further along the pipeline, updates to the branch prediction tables can introduce further challenges to the process because additional write ports to each prediction table for handling updates based on the outputs from the two branch execution units result in more hardware, but a single write or read / write port limits the amount of updates per cycle. Therefore, there is a need for improvements to the pipeline architecture to improve the pipeline instruction flow, thereby improving the speed and efficiency of instruction execution in the microprocessor. Summary of the Invention

[0004] In one embodiment, a branch handling method includes: receiving information from at least two branch execution units; writing two updates to corresponding first and second write queues in each clock cycle based on the information; and writing up to two updates from the first write queue to multiple tables of a first predictor in each clock cycle, and in the event of an expected write conflict, writing a single update for a single clock cycle, wherein the first predictor includes a single write or read / write port.

[0005] Other systems, methods, features and advantages of the present invention will be or become apparent to those skilled in the art by examining the following drawings and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the present invention, and be protected by the following claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The various aspects of the present invention may be better understood with reference to the following drawings. The components in the drawings are not necessarily drawn to scale, but emphasis is placed on clearly illustrating the principles of the present invention. In addition, in the drawings, the same reference numerals throughout the various figures refer to corresponding parts.

[0007] Figure 1A is a block diagram illustrating an exemplary branch unit pipeline of a microprocessor implementing an embodiment of the branch processing system.

[0008] Figure 1B It shows Figure 1A A schematic diagram of an exemplary front end of a branch unit pipeline is shown.

[0009] Figure 2A is a schematic diagram illustrating an embodiment of an exemplary format phase branching unit for implementing dual branch formatting of an embodiment of a branch processing system.

[0010] Figure 2B is a flow chart illustrating an embodiment of an exemplary method of dual branch formatting for an embodiment of a branch processing system.

[0011] Figure 3A is a schematic diagram of an embodiment of a dual branch update system illustrating an embodiment of a branch processing system.

[0012] Figure 3B is a flow chart illustrating an embodiment of an exemplary method of dual branch update for an embodiment of a branch handling system.

[0013] Figure 4 is a flow chart illustrating an embodiment of an exemplary branch processing method.

[0014] Figure 5 is a flow chart illustrating an embodiment of another exemplary branch processing method. DETAILED DESCRIPTION

[0015] Certain embodiments of a branch processing system and method are disclosed, providing an efficient and simplified hardware design for decoding and updating branch pairs in a branch unit pipeline of a microprocessor. In one embodiment, a format stage decode branch unit is configured to write primary and secondary branch information (e.g., branch address, prediction table used, etc.) to a branch order table (BOT), wherein only logic for checking the target address of the displacement branch of the primary branch information is required, depending on whether the branch instruction is assigned as primary or secondary branch information. In other words, given the assignment, the primary and secondary branch information are routed along separate pipeline processing paths with different hardware complexities. In some embodiments, the branch processing system further includes two write queues to delay updates to a given branch predictor table (also referred to as an array) with a single write or read / write port when the write or read / write port is currently in use. In one embodiment, the write queues only issue a single update if a conflict is expected (e.g., writes to the same table or sub-table), wherein the determination of which of multiple updates to write is based on a determination of the importance of the branch instruction. In the absence of an expected conflict, the write queues each allow multiple updates for a given clock cycle. By allocating and routing two branch instructions via primary and secondary branch information, and / or determining an update to a given predictor table from one of the write queues based on importance in the event of an anticipated conflict, instruction bandwidth is more evenly matched throughout the pipeline while improving processing speed and reducing hardware complexity in a format stage decode branch unit without increasing table size (e.g., by adding ports).

[0016] In short, microarchitectures have been developed today to concurrently process and send two branch instructions along the branch pipeline for decoding and execution. However, potential bottlenecks may need to be addressed through additional adder (adder logic) hardware and / or multiple predictor table write ports, which increases chip complexity, cost, and, of course, size. In contrast, certain embodiments of the branch processing system disclosed herein selectively route branch instructions in a manner that reduces the need for additional adder logic, and / or incorporates two write queues in the branch update stage to eliminate the need for additional predictor table write ports, while ensuring acceptable high performance in the branch instruction flow throughout the pipeline.

[0017] Having summarized certain features of the branch processing system of the present invention, reference will now be made in detail to the description of the branch processing system as shown in the accompanying drawings. Although the branch processing system will be described in conjunction with these drawings, it is not intended to limit it to one or more embodiments disclosed herein. That is, although the present invention is susceptible of modification and alternative forms, its specific embodiments are shown by way of example in the drawings and will be described herein in detail enough to be understood by those skilled in the art. However, it should be understood that the drawings and their detailed description are not intended to limit the invention to the specific form disclosed. On the contrary, the present invention will cover all modifications, equivalents and alternatives that fall within the spirit and scope of the invention as defined by the appended claims. As used throughout this application, the word "may" is used in a permissive sense (i.e., meaning potentially) rather than a mandatory sense (i.e., meaning must). Similarly, the word "include" means including but not limited to.

[0018] Various units, modules, circuits, logic, or other components may be described as being "configured to" perform one or more tasks. In this context, "configured to" is a broad description of structure, which generally means "having circuitry or other physical structure" that performs or is capable of performing one or more tasks during operation. A circuit may be a dedicated circuit or a more general processing circuit that operates under the control of coded instructions. That is, terms such as "unit," "module," "circuit," "logic," and "component" may be used herein when describing certain aspects or features of various implementations of the present invention. Those skilled in the art will understand that the corresponding features are implemented using circuitry, whether that circuitry is a dedicated circuit or a more general circuit that operates under the control of microcoded instructions.

[0019] In addition, a unit / module / circuit / logic / component can be configured to perform a task even when the unit / module / circuit / logic / component is not currently in operation. The description of a unit / module / circuit / logic / component as being configured to perform one or more tasks is expressly intended to be without functional limitations on the unit / module / circuit / logic / component. In this regard, those skilled in the art will appreciate that the specific structure or interconnection of circuit elements will typically be determined by a compiler of a design automation tool, such as a register transfer language (RTL) compiler. An RTL compiler operates on a script that is very similar to assembly language code to compile the script into a form for layout or fabrication of the final circuit.

[0020] That is, integrated circuits (such as the integrated circuit of the present invention) are designed using higher-level software tools to model the desired functional operation of the circuit. As is well known, "electronic design automation" (or EDA) is a category of software tools used to design electronic systems (such as integrated circuits). EDA tools are also used to program design functions into field-programmable gate arrays (FPGAs). Hardware description languages ​​(HDLs) such as Verilog and Very High Speed ​​Integrated Circuits (VHDL) are used to create a high-level representation of the circuit, from which low-level representations and ultimately the actual wiring can be derived. In fact, because modern semiconductor chips can have billions of components, EDA tools are considered essential for their design. In practice, circuit designers use programming languages ​​such as C / C++ to specify operational functions. EDA software tools convert this specified function into RTL. The hardware description language (e.g., Verilog) then converts the RTL into a discrete gate netlist. This netlist defines the actual circuit produced by, for example, a foundry. In fact, these tools are well known and understood for their role and use in facilitating the design process of electronic and digital systems, and therefore do not need to be described herein.

[0021] Figure 1A An embodiment of an exemplary branch unit pipeline of the microprocessor 10 is shown. It should be understood that certain known components of the microprocessor 10 have been omitted herein for the sake of brevity and ease of explanation and illustration. As is known, a pipeline architecture provides for multiple instructions that overlap in execution, with various stages referred to as pipeline stages. The blocks shown in the branch unit pipeline may each be implemented in accordance with one or more stages, which are shown to the left of the blocks and are represented in the depicted embodiment by capital letters C, I, B, U, L, M, F, G, W, X, E, S, W, Y, and Z that progress sequentially from top to bottom and are redirected (as indicated by arrows). One of ordinary skill in the art will appreciate that Figure 1A The number and / or arrangement of stages depicted in the figures illustrate only one exemplary embodiment, and in some embodiments, a different number and / or arrangement of stages may be implemented and are therefore contemplated to be within the scope of the present invention. One of ordinary skill in the art will also appreciate that the blocks provide a general description of the functionality of a branch pipeline, and that associated logic or circuitry known to one of ordinary skill in the art has been omitted herein for the sake of brevity. For example, one of ordinary skill in the art will appreciate that the stages of a pipeline may be separated by clock pipeline registers or latches, as is known. As another example, while Figure 1A It is not explicitly shown in the figure, but it should be understood by those skilled in the art that the operations at the front end involve data exchange or interaction with the instruction cache.

[0022] The instruction cache is a random access memory device within a microprocessor. The microprocessor places into the instruction cache instructions of an ISA machine language program (such as x86 ISA machine language instructions) that were recently fetched and / or pre-fetched from a larger cache (e.g., L2 cache, L3 cache) or system memory (e.g., fetched and / or pre-fetched from DRAM via a bus interface unit) and executed by the microprocessor while executing the ISA machine language program. The ISA defines an instruction address register (defined by the x86 ISA as the instruction pointer (IP), but sometimes referred to as the program counter (PC)) that holds the memory address of the next ISA instruction to be executed. The microprocessor updates the contents of the instruction address register as it executes the machine language program to control the program's flow. To facilitate faster retrieval of ISA instructions from the instruction cache based on the contents of the instruction address register rather than from system memory during the next execution of the machine language program, ISA instructions are cached, with the register holding the memory addresses of ISA instructions stored in the instruction cache. Specifically, the instruction cache is accessed based on the memory address held in the instruction address register (e.g., IP), rather than exclusively based on the memory address specified by a load or store instruction. Thus, a dedicated data cache that holds ISA instructions as data (such as might be present in the hardware portion of a system employing a software translator, etc.) and that is accessed exclusively based on load / store addresses rather than via instruction address register values ​​is not an instruction cache. Furthermore, for purposes of the present invention, a unified cache that caches both instructions and data (i.e., that is accessed based on instruction address register values ​​and load / store addresses rather than exclusively based on load / store addresses) is intended to be included within the definition of an instruction cache.

[0023] Special attention Figure 1A The branch unit pipeline of the microprocessor 10 includes a pipeline microprocessor. In one embodiment, the instruction set of the pipeline microprocessor substantially conforms to the x86 architecture instruction set. As will be understood by those skilled in the art from the description provided herein, the present invention can be implemented in a variety of different circuit structures and architectures, and Figure 1AThe architecture shown in is only one of many suitable architectures. The exemplary microprocessor 10 includes a fast predictor 12, a branch target address cache (BTAC) 14, an instruction byte queue (XIB) 16, a branch decoder 18 (including a format (F) stage decoding branch unit, or also referred to as an F stage branch unit in this article), a format instruction queue (FIQ) / loop queue 20, an instruction translator 22, a register alias table (RAT) / reservation station (RS) 24, a functional unit (e.g., an integer unit, a floating point unit, etc.) 26, and a branch table updater 28 (in one embodiment, including two write queues). The boxes referenced by the respective numerals of the microprocessor 10 correspond to logic circuits implemented on corresponding multiple stages C, I, B, U, L, M, F, G, W, X, E, S, W, Y and Z, wherein the pipeline architecture enables different instruction groups at each stage. In one embodiment, four or more instructions can be run at each stage, wherein control signals mark each stage along the pipeline. The stages associated with the fast predictor 12, BTAC 14, and XIB 16 involve accessing the instruction cache (I-cache). Figure 1A access (not shown).

[0024] The fast predictor 12 includes a single-cycle branch predictor that provides a single-cycle prediction (e.g., takes one cycle to generate a target address, which is provided in the I stage in one embodiment). In one embodiment, the fast predictor 12 includes a table (also referred to herein as an array or target array) that stores branch target addresses of previously executed branch instructions, which implements branch prediction when the stored branch instructions are subsequently encountered. In one embodiment, the table includes 128 entries, but tables of other sizes (e.g., 64 entries, 32 entries, etc.) may be used in some embodiments. The table is organized as an n-way (e.g., n is an integer greater than 1) set associative cache. In one embodiment, each entry stores eight (8) 3-bit counters and the current local branch mode, where the counters are selected by the 3-bit local branch mode. The fast predictor 12 also includes a conditional branch predictor that is accessed in parallel with the table and provides a taken / not taken direction for conditional branches. The fast predictor also includes a return stack that can provide targets instead of a table. In one embodiment, the return stack includes four (4) entries and provides targets for return instructions. Note that the specifications listed above are for illustration only, and some embodiments may operate under different specifications and are therefore contemplated to be within the scope of the present invention. The fast predictor 12 is configured to deliver a predicted branch target immediately (within a single cycle) without applying a branch penalty. In some embodiments, the fast predictor 12 may operate according to other specifications of its prediction mechanism and / or table configuration, or in some embodiments, the fast predictor 12 may be omitted. Most branches are correctly predicted by the fast predictor 12. In some embodiments, in the event that the fast predictor 12 provides a branch prediction that is different from the branch prediction of the BTAC 14 (e.g., different in direction and / or target) based on the same fetched branch instruction, the BTAC 14 utilizes the branch prediction information provided by the BTAC 14 (e.g., direction, target address, branch prediction type) to overwrite the branch prediction of the fast predictor 12 and update the fast predictor table within a set of stages of the BTAC 14 (e.g., in the U stage).

[0025] The I stage and / or B stage correspond to accessing various tables of the branch unit pipeline (including the I cache, tag array, translation lookaside buffer (TLB) array, BTAC array, return stack array, etc.), giving directions or ways through multiplexing (e.g., based on tags), and reading instructions.

[0026] The BTAC 14 maintains information related to previously executed branch instructions that it uses to predict the target address, direction, and type during subsequent execution. The BTAC 14 includes one or more tables that are significantly larger than the tables of the fast predictor 12. In one embodiment, the BTAC 14 includes a 4k-entry, m-way set-associative table (also referred to herein as an array or target array), where m is an integer greater than 1. Each entry in the BTAC 14 includes a valid bit, a branch target address prediction, a direction prediction, and a branch type. The branch type specifies whether the branch instruction is a call / return, an indirect branch, a conditional relative branch, or an unconditional relative branch. In one embodiment, the BTAC 14 includes or cooperates with a conditional relative branch predictor having a multi-entry (e.g., 12k) tag geometry length (TAGE)-based predictor, multiple tables, a multi-bit (e.g., 3-bit) taken / not taken (T / NT) counter, and a multi-bit global branch history. As another example, indirect prediction includes a multi-entry (e.g., 1.5k) TAGE predictor and uses table entries for static indirect branches. Note that in some embodiments, other types of prediction mechanisms may be used, including correlation-based prediction mechanisms, predictors that use a combination of global and local branch histories, and the like. For each portion or fetch of a cache line of the instruction cache (e.g., 16 bytes), the BTAC 14 may maintain three entries (e.g., edges A, B, and C, although fewer edges may be used in some embodiments to store prediction information for fewer branch instructions), which may hold prediction information for up to three branch instructions that may be present in a portion of the cache line. The BTAC 14 includes operations that proceed through a set of stages (e.g., I, B, and U stages). In practice, the U stage of a branch instruction serves as the C stage of the target (e.g., the arrow from the B stage to the C stage reflects the situation where the branch instruction is in the B stage, and the next clock is the C stage of the target, or in this case, the cache address), resulting in a two-clock delay in the BTAC prediction.

[0027] The BTAC 14 has a two-clock taken penalty, which also reveals the benefits of fast branch prediction (no taken penalty) provided by the fast predictor 12 by immediately directing the new cache address as the target. In one embodiment, the BTAC 14 is larger than the fast predictor 12 and has a more complex branch prediction mechanism that is configured to (e.g., always) rewrite the branch prediction of the fast predictor 12 when there is a discrepancy in the branch prediction (e.g., the branch prediction determined by the BTAC 14 differs from the taken decision and / or branch target address determined by the fast predictor 12). In some embodiments, the BTAC 14 is configured to update the fast predictor 12 during one of the BTAC phases (e.g., the U phase) by writing branch prediction information to the tables of the fast predictor 12 (and also to the tables of the BTAC 14). In some embodiments, the update of the BTAC 14 is delayed until the branch is executed or retired, wherein the update of the BTAC 14 involves writing to the BTAC tables and / or the TAGE tables. As further described below, in one embodiment, the updates involve target information updates and / or counter updates, and two write queues are used for the updates to provide up to two updates each in a single clock cycle. However, updates to the fast predictor 12 do not wait for that period of time, but occur during the BTAC phase. Note that branches that are not in the fast predictor 12 are written to the fast predictor 12 two cycles later at a time corresponding to the BTAC phase (e.g., during the BTAC phase).

[0028] The XIB 16 is a queue of entries, each entry holding 16 bytes of data from the instruction cache. For example, the cache data from the XIB 16 is simply a stream of instruction bytes in 16-byte blocks, and given that instructions have variable lengths, it is unknown where a given x86 instruction begins or ends within a stream or within a given block. The XIB 16 includes known logic to determine and mark the start and end bytes of each instruction within the stream, thereby breaking the byte stream into an x86 instruction stream, which is provided to and stored in the FIQ / loop queue 20 for processing by the rest of the microprocessor pipeline. In the L (length) stage, the XIB 16 determines the instruction length. In one embodiment, the pre-decoder ( Figure 1A) is implemented at the U stage and is configured to detect potential branch instructions and mark them as such for each instruction byte in the queue. Note that at this stage, there is ambiguity as to whether a given byte is the beginning of an instruction. If the byte is the opcode byte of a branch instruction determined later (M stage), the instruction is confirmed to be a branch instruction. For example, the branch decoder 18 includes instruction multiplexing (not shown) for multiplexing instructions in a multiplexing or M stage, where branch instructions are confirmed as such. The instruction multiplexing also determines (in the M stage) whether each branch instruction includes primary branch information or secondary branch information, and assigns or specifies branch instructions accordingly. In one embodiment, the instruction multiplexing routes the identified branch instructions along pipeline paths with different hardware complexities based on whether the branch instruction is assigned as primary branch information or secondary branch information. As further described below, in the F-stage decoding branch unit of the branch decoder 18, the branch target of the displacement branch is checked only for the main branch information, and the main branch information (including the target of the checked displacement branch) and the secondary branch information (excluding the branch target) are written to the branch order table (BOT).

[0029] In the F stage, these instructions are formatted as described above. In one embodiment, the formatted instructions include instructions that substantially conform to the x86 architecture instruction set. Furthermore, in the M stage, a determination is made as to whether a given instruction (possibly pre-marked by a pre-decoder) is indeed a branch. For example, in the event of a miss in the fast predictor 12 or BTAC 14 (e.g., at initial startup), the branch decoder 18 (e.g., instruction multiplexing) determines that the current instruction is a branch, writes to the BOT, and in stage G redirects the cache address to the new target and updates the table in the front end of the microprocessor 10. In practice, when a miss occurs in the fast predictor 12 or BTAC 14, the branch decoder 18 provides a branch prediction, with the branch instruction being redirected to the target in the C stage. In some cases, such as when there are more than a finite or predetermined maximum number of branches for each fetch at the BTAC 14 (e.g., more than three branches for each 16-byte fetch), branch prediction for the additional branches is delayed until decode time.

[0030] The FIQ / loop queue 20 receives formatted instructions and buffers them until they can be translated into microinstructions. The FIQ / loop queue 20 also provides preliminary decoding and fast loop functions (e.g., on a BTAC loop branch, the loop queue is activated and loop instructions are repeatedly issued), the latter represented by the arrow to the right of the box 20.

[0031] The W phase provides an optional additional timing clock.

[0032] In the X stage, the instruction translator 22 (in the X stage or translation stage) translates the formatted instructions stored in the FIQ / loop queue 20 into microinstructions.

[0033] Instructions are provided to the Register Alias ​​Table / Reservation Table (RAT / RS) 24 in program order. The RAT function of the RAT / RS 24 maintains and generates dependency information for each instruction. The RAT function of the RAT / RS 24 renames the source and destination of the instruction to internal registers and dispatches the instruction to the reservation station of the RAT / RS 24, which issues the instruction (possibly out of program order) to the functional unit 26. The functional or execution unit 26, including the integer unit, executes the branch instruction in stage E (execution). The execution unit, branch unit, and integer unit are terms used interchangeably herein. In one embodiment, the execution unit 26 (e.g., two execution units) executes two branches in a single clock cycle. The execution unit 26 also indicates to the BTAC 14 whether the branch instruction has been correctly predicted.

[0034] In one embodiment, the results of the execution are provided to a reorder buffer (not shown), which includes information about the instructions that have been executed. As is known, the reorder buffer maintains the original program order of the instructions after they are issued and allows for serialization of results during the retirement phase. In one embodiment, some of the information that is traditionally stored in the reorder buffer is instead stored in a BOT, which has a significantly smaller size (e.g., forty-eight (48) entries in the BOT compared to 192 entries in the reorder buffer). For example, the information stored in the BOT may include 200 to 250 bits of branch information, such as the type of branch, the branch mode, the target, the table used in the prediction, and cache replacement policy information (e.g., least recently used or LRU). Note that the amounts of bits and / or entries described herein are used as illustrative examples only, and other values ​​may be used in some embodiments.

[0035] The branch table update 28 includes stages S, W, Y, and Z and is configured to update various tables at the front end (e.g., BTAC, TAGE) with information related to a fully decoded and executed branch instruction (e.g., the final outcome of the branch) (e.g., in the S stage). At stages S, W, Y, and Z, the updates may involve table reads, target address writes, and counter increments or decrements, which may involve some latency. In one embodiment, the branch table update 28 includes two write queues, each of which can be used to handle up to two updates (e.g., to the BTAC table, the TAGE table, or a combination of the two) in a single clock cycle. As described above, the queues enable delays in updating until an appropriate time. In one embodiment, in the event of an anticipated conflict, the control logic determines which of the queued branch information to write to a given table based on a priority scheme (e.g., relative importance) at an appropriate time.

[0036] Now refer to Figure 1B , continue to refer to Figure 1A , shown in the case of Figure 1A 1 and 2. A microprocessor 10 is shown illustrating an example fast predictor 12 and other example sources used at the front end 30 of the branch unit pipeline. The front end 30 includes a fetch unit 32 (e.g., including multiplexing and clock registers), a translation lookaside buffer (TLB) 34, an instruction cache (I-cache data) 36, an I-cache tag 38 (or tag array), the BTAC 14, and the fast predictor 12. The fetch unit 32 receives multiple sources of cached instruction addresses, including sequential instruction addresses (e.g., from the I stage), corrected instruction addresses (e.g., from the S stage), decode-time instruction addresses (e.g., from the G stage), and addresses from the BTAC 14 and the fast predictor 12. The output of the fetch unit 32 is a cache address that is provided as input to the TLB 34, the I-cache data 36, ​​the I-cache tags 38, the BTAC 14, and the fast predictor 12 for the next instruction to access the I-cache data 36.

[0037] The TLB 34 provides virtual-to-physical page address translation, as is known, under the management of a memory management unit (not shown). That is, the TLB 34 stores the physical addresses of recently used virtual addresses. The TLB 34 receives a linear address from the segmentation unit (which converts logical addresses from the program into linear addresses) and compares a portion of the linear address with an entry in the TLB 34 to find a match. If there is a match, the physical address is calculated based on the TLB entry. If there is no match, the page table entry from memory is retrieved and placed in the TLB 34.

[0038] The I-cache data 36 includes a level 1 cache of instructions that have been fetched or pre-fetched from L2, L3, or main memory. The I-cache data 36 includes a plurality of clock registers.

[0039] The I-cache tags 38 include a tag array corresponding to the instructions in the I-cache data 36 and include multiple clock registers and are used to determine a match between information associated with a fetched cache instruction (e.g., a tag or portion of a cache address) and the I-cache data 36 and the BTAC 14.

[0040] Combined with the above Figure 1A A BTAC 14 is illustrated and has multiple clock registers and a two (2) clock take penalty. The fast predictor 12, also described above, has a zero (0) clock take penalty. For example, assume fetches along the I cache at 16 bytes per cycle, and assume a branch instruction from cache address 20 to cache address 95. Note that hexadecimal notation is implied by the address descriptions in this example (e.g., 0x0, 0x10, 0x20, etc.). Thus, fetches occur at cache address 0, cache address 10, cache address 20 (the branch instruction, but this is not resolved because the BTAC 14 reads and multiplexes across multiple cycles, which in some embodiments are the same timing as the I cache), cache address 30 (relative to clock 1), cache address 40 (relative to clock 2), and then on the third clock (relative to clock 3), the cache instruction fetch is redirected to cache address 95. Therefore, the branch penalty taken in this example includes two clock cycles because cache addresses 30 and 40 occur after the branch. In other words, without the fast predictor 12, for this particular design example, the branch penalty taken is always two clocks. With the smaller and faster fast predictor 12, cache address fetches (in the above example) include 0, 10, 20, and 95, with no delay for the cache address and a penalty of zero taken. As mentioned above, in some embodiments, the fast predictor 12 can be omitted.

[0041] Continue to refer Figures 1A to 1B ,focus on Figure 2A , which shows an embodiment of a branch processing system, an embodiment of a format (F) stage decoding branch unit 40 configured to implement dual branch formatting. It should be understood by those skilled in the art that Figure 2AThe schematic diagram depicted in FIG is illustrative of one exemplary embodiment, and some embodiments may provide different microarchitectures including different logic and / or different arrangements of logic than depicted to perform similar functionality. I-cache data 36, ​​pre-decoder 42, XIB 16 including instruction length tag logic 44, branch decoder 18 including instruction multiplexing 46, F-stage decode branch unit 40 and instruction decoder 48, and FIQ / loop queue 20 are shown.

[0042] The instruction from the I-cache data 36 can originate from one of several situations. For example, the instruction can be one or more branch instructions that have not been encountered previously or have missed at the BTAC 14. In addition, the instruction can include a branch instruction that is sent through the rest of the pipeline (e.g., XIB 16, branch decoder 18, FIQ / loop queue 20, etc.) for further processing and inspection, thereby ultimately undergoing processing by two branch execution units 26 (e.g., checking condition codes, checking targets to ensure correct predictions, etc.) and updates by the branch table update 28. In order to avoid or eliminate instruction bandwidth mismatches at different stages of the pipeline, the decoding of the two branches should have the ability to execute both branches. Certain embodiments of the branch processing system are configured to achieve this consistent instruction bandwidth through the pipeline.

[0043] As described above, pre-decoder 42 (or pre-decode logic) is configured to detect potential branch instructions. Note that in some embodiments, pre-decoder 42 can be located elsewhere in the pipeline. Pre-decoder 42 marks instructions, including identification of branches, prefixes, etc., and pre-decode information appended to the instruction bytes fed back to XIB 16. In practice, pre-decoder 42 performs preliminary or partial decoding, while instruction decoder 48 performs full instruction decoding.

[0044] XIB 16 includes instruction length tag logic 44 implemented in the L or length stage. Information regarding branch length tagging (to the extent such information is supplemental and consistent with the teachings of the present invention) can be found in U.S. Patent 8,473,862, which is incorporated herein by reference.

[0045] The branch decoder 18 includes, in one embodiment, instruction multiplexing or instruction multiplexing logic 46 (multiplexing stage or M stage), implemented in stages M, F, and G, an F stage decode-branch unit 40, and instruction decode logic 48. Information regarding the M and F stages (to the extent such information is supplemental and consistent with the teachings of the present invention) can be found in U.S. Patent No. 8,473,862, which is incorporated herein by reference. The instruction multiplexing 46 is configured to assign or designate branch instructions as either primary branch information or secondary branch information. In one embodiment, primary branch information includes the following branches for a given clock cycle: the only branch in the cycle, the first taken branch, an unpredicted branch, or the second not-taken branch. In one embodiment, secondary branch information always includes the first not-taken branch before another branch for that cycle. The instruction multiplexing logic 46 is further configured to route the primary branch information and secondary branch information to the F stage decode-branch unit 40 and provide a plurality (e.g., four) instructions to the instruction decoder 48 for full instruction decode processing for delivery to the FIQ / loop queue 20.

[0046] Generally, the F stage, or formatting stage, is an early stage of decoding that decodes instructions and sends them down the pipeline for further processing (e.g., translation, execution, etc.) Any branches predicted (or not predicted) by the BTAC 14 are checked in the F stage. For example, self-modifying code or aliased addresses may cause what is determined to be a speculatively predicted branch to not actually be a branch.

[0047] The F-stage decoded branch unit 40 includes an adder (adder logic) 50, which adds the instruction pointer to the displacement extracted from the primary branch information instruction to derive the target address of the displacement branch; a comparator 52, which compares the derived target address with the BTAC target address; and a BOT 54, which stores primary branch information, which includes the target address of the displacement branch, and secondary branch information, which does not include the target address. For primary branch information, the target address of the displacement branch calculated at the F-stage decoded branch unit 40 is checked against the BTAC target address to ensure that the target predicted by the BTAC is correct. If the BTAC 14 provides an incorrect branch target address for the displacement branch, the correct target address is updated at the BTAC 14, and the I-cache data 36 is redirected (signaled in stage G) to the correct target.

[0048] The two branches formatted by the F-stage decode branch unit 40 are written to the BOT 54 in a single clock cycle. In one embodiment, only one (displaced branch) target derived from the primary branch information is written to the BOT 54. The branch information written to the BOT 54 includes branch information such as the type of branch, branch mode information and direction and validity, and the displacement branch target address in the case of the primary branch information. For example, only one taken branch is allowed in a given clock cycle, while the not-taken branch of the secondary information is never taken, so there is no need to save the target. However, two sets of addition and comparator logic can achieve the processing of two branches per cycle. In some embodiments of the branch processing system, only a single set of addition and comparator logic is used for the primary branch information (because the secondary branch information is always the not-taken branch before the other branch). The latter arrangement achieves a reduction in hardware (e.g., fewer adders, less multiplexing, etc.) and faster timing.

[0049] When executed, the instruction has a pointer (eg, a tag or address) that references the BOT 54, which is read and used to update the BTAC table or TAGE table.

[0050] Now refer to Figure 2B , illustrates an embodiment of an exemplary branch handling method, and in particular, illustrates a method of dual branch formatting of an embodiment of a branch handling system, shown as method 56. Method 56 retrieves data from the I cache 36 ( Figure 1B ) receives up to two branch instructions (58) and determines whether the received branch instruction is the first not taken (NT) branch before another branch in a clock cycle (60). If so ("yes" of 60), the branch is allocated or equivalently designated (e.g., by instruction multiplexing 46) as secondary branch information (62) and written (without target) to the BOT (64).

[0051] If not ("No" at 60), a determination is made (e.g., by instruction multiplexing 46) as to whether the branch is the only branch for the given clock cycle (66). If so ("Yes" at 66), the branch is designated as master branch information (68), the target of the displaced branch is checked against the BTAC target (e.g., at the F-stage decode branch unit 40) (74), and the master branch information (including the corresponding checked displaced branch target) is written to the BOT (64).

[0052] If not ("No" at 66), a determination is made (e.g., by instruction multiplexing 46) as to whether the branch is the first taken branch or an unpredicted branch for a given clock cycle (70). If so ("Yes" at 70), the branch is designated as primary branch information (68), the target of the displaced branch is checked against the BTAC target (74) (e.g., at the F stage decode branch unit 40), and the primary branch information (including the corresponding checked displaced branch target) is written to the BOT (64).

[0053] If not ("No" at 70), a determination is made (e.g., by instruction multiplexing 46) that the branch is the second not-taken branch for the given clock cycle (72), and the branch is designated as the primary branch information (68), the target of the displaced branch is checked against the BTAC target (e.g., at the F-stage decode branch unit 40) (74), and the primary branch information (including the corresponding checked displaced branch target) is written to the BOT (64).

[0054] Note that in some embodiments, the order of these steps 60, 66, 70, and 72 can be rearranged, or in some embodiments, certain steps can be performed concurrently (e.g., steps 66 to 72). Thus, through this dual-branch formatting method 56, only one pipeline processing path of the F-stage decode branch unit 40 needs to have adder logic to handle the processing of the main branch information (e.g., branch displacement target), and both the main branch information and the secondary branch information are written to the BOT, making it possible to reduce hardware, latency, and complexity (e.g., by using a path for the secondary branch information with reduced complexity).

[0055] Figures 2A to 2B The dual branch formatting method 56 and underlying logic shown in 56 enable two branch instructions to be formatted (in a single cycle) so that the two branch instructions can be executed in parallel. Figure 3A, which illustrates an embodiment of a dual branch update system 76 of an embodiment of a branch processing system. The dual branch update system 76 continues to benefit from processing two branch instructions at a time by using two write queues to delay writes to a single port while a front-end read is in progress, while enabling up to two updates per write queue to the branch predictor's tables (e.g., BTAC, TAGE). For example, writes can be delayed until a cycle in which there are no active read accesses in the front-end (e.g., the front-end is stalled). As explained above, having a branch predictor with only one corresponding write or read / write port (and even sub-tables) provides benefits in terms of table size reduction (when compared to an array or table with two write ports, e.g., doubling the size of the table when going from a single write port to two write ports), but also presents challenges (e.g., delays or bottlenecks) for updates when more than one branch instruction is involved. As further explained below, certain embodiments of the dual branch update system 76 address one or more of these challenges by using two write queues, each of which is capable of writing up to two updates. In one embodiment, the control logic communicates with the branch table update logic and the predictor logic table, evaluates the potential for conflicts (e.g., two branches writing to the same table or sub-table), and (when appropriate) updates the branch predictor table (or sub-table) from the write queue via either two branch writes (no expected conflicts) or a prioritized single write to one of the tables (when there is an expected conflict). For example, if there is an expected conflict (e.g., writes to the same side of the table) in the bottom two entries of the write queue, then one of the write queues sends a single update, with the selected update being based on the importance of the branch instruction information.

[0056] The dual branch update system 76 includes write logic 78A, 78B that receives branch execution outputs (e.g., misprediction signals and branch tags) from branch units IU1 26A and IU2 26B (e.g., the address of the branch in the BOT, which allows access to other branch information, including which sides to use in the BTAC or TAGE array, which table to use in the condition predictor, etc.). Note that in some embodiments, the write logic 78A, 78B can be embodied as two instances of programming code. The dual branch update system 76 also includes branch table update 28 ( Figure 1A) are two write queues 80 (BTAC) and 82 (TAGE), each of which is configured to store updates and then write two updates to the multi-edge (e.g., edge A, edge B, and edge C) BTAC table 84, the multi-edge TAGE table 86 (e.g., edge A, edge B, and edge C, which is a prediction method for conditional branch prediction and indirect branch prediction using branch pattern information, with different tables used to provide taken / not taken determinations), or to both the BTAC table and the TAGE table at the appropriate time. Control logic provides evaluation of importance, appropriate update timing, and coordination between branch table updates and the prediction logic.

[0057] In short, and as at least partially described above, the branch predictor in one embodiment of the branch handling system includes the BTAC 14, the TAGE conditional predictor, the TAGE indirect predictor, and the BTAC return stack. The return stack only needs to be updated on mispredictions, which is achieved in one embodiment via a reset of the read / write pointer. Each predictor includes a table (and sub-tables) that has a single port (read / write, or write) but can be written to independently of other tables (and sub-tables). For example, the BTAC 14 can be written to simultaneously with the conditional predictor, etc. For example, if the branch is on edge A of the BTAC 14, then edge A of the TAGE table 86 can be used (if necessary). The BTAC 14 includes a main table that determines whether the branch will be fully predicted (e.g., a hit must be obtained in the BTAC), and it includes a type bit that indicates the type of branch. In one embodiment, the BTAC 14 includes three (3) edges or tables (A, B, C, but a different number of edges may be used in some embodiments) to handle three (3) branches for each pick. In addition, there is a separate TAGE condition predictor for each of at least edges A and B (tables A and B). In some embodiments, a simpler gshare predictor may be used for edge C, but in some embodiments, a TAGE condition predictor may also be used for edge C. Note that TAGE is an exemplary prediction mechanism, and in some embodiments, other predictors may be used, including any one or a combination of global or local branch based predictions. Each TAGE condition predictor has multiple tables (e.g., nine (9) tables for illustration, but other numbers are also contemplated). Thus, in an exemplary embodiment, there are a total of eighteen (18) TAGE condition tables (and in some embodiments, there is an additional single gshare table).

[0058] In one embodiment, writing to the write queues 80 and 82 involves multiple (e.g., two (2)) writes per clock cycle, but in some embodiments, only a single branch is written during a given clock cycle. In one embodiment, updating the BTAC table 84 involves reading two (2) updates from the queues 80 and / or 82 and two writes to different edges A, B, C (no conflicts). In one embodiment, updating the TAGE table 86 involves reading two (2) updates from the queues 80 and / or 82 and two writes to different edges A, B, C (no conflicts). In some embodiments, both the BTAC table 84 and the TAGE table 86 may be updated. Note that writing to the TAGE table 86 and the BTAC table 84 is typically separate, but may be performed simultaneously to adjust confidence in the prediction mechanism (e.g., may involve bias adjustments, or indications of take or no take decisions for less or more reliable predictions). Note that writes may be made to either a sub-table of table 84 or table 86. Thus, there are no conflicts as long as the two writes involve different edges, different tables, or different sub-tables. The updates may include adjustments to counters (e.g., increments for correct predictions, decrements for incorrect predictions, adjustments to mispredicted targets, etc.). The updates may be performed at suitable times and, in the case of two updates, in parallel. Suitable times may include when the array is available for writing or when a write queue reaches a predefined fullness or pending (e.g., an update is in the queue for, for example, twelve (12) clock cycles). In some embodiments, the I-cache may be paused to enable these updates. For example, the clock cycles are monitored to determine if there are delays or pauses in I-cache accesses (such as from snoop operations, infinite loops, etc.).

[0059] If conflicts are anticipated (e.g., based on identifying updates to entries of the same table or sub-table), then for a given update cycle, updates are prioritized (e.g., by control logic). As an example, assume that the outputs of branch execution units 26A and 26B include concurrent mispredicted branches. In one embodiment, for the purposes of updating, the most important branch is the older branch (because the newer or later branch is mispredicted as deviating from the older branch).

[0060] As another example, in the event of an anticipation conflict, updates to TAGE table 86 may result in updates being determined to be mispredicted to be more significant than correctly predicted updates (eg, particularly if the correct prediction counter is saturated).

[0061] As another illustrative example, in some cases (e.g., a conditional branch is correctly predicted), the update involves a read-modify-write update. If the branch goes to different edges (e.g., A, B, C), then two of these updates can be processed per clock cycle. Otherwise, the updates can be queued or one can be discarded (or bypassed later).

[0062] Given that Figure 3A The description of the dual branch update system 76 should be understood that an embodiment of the exemplary branch processing method, specifically the dual branch update method (in Figure 3B An embodiment (represented as method 88 in FIG) includes determining whether a table update opportunity exists (e.g., cache pause, queue fullness, etc.) (90). If not (90 is "no"), monitoring continues, otherwise ("yes"), a determination is made as to whether a conflict is expected (92). If so (92 is "yes"), the most significant branch is selected (e.g., older, mispredicted versus correctly predicted, etc.) (94) and an update to the predictor table is performed (96). Otherwise (92 is "no"), both branches are updated from the write queue (96). One of ordinary skill in the art will appreciate that variations in the arrangement or order of steps are contemplated within the context of the present invention, some of which may be performed concurrently or in parallel. Figure 3B The different orders are described.

[0063] Having described certain embodiments of a branch processing system, it will be appreciated that one embodiment of an exemplary branch processing method (in Figure 4 98) includes assigning a plurality of branch instructions for a given clock cycle to primary branch information and secondary branch information (100); routing the primary branch information along a first path having adder logic and routing the secondary branch information along a second path not having adder logic (102); and writing the primary branch information including a displaced branch target address to a branch order table (BOT) and writing the secondary branch information without a target address to the BOT (103).

[0064] Having described certain embodiments of a branch processing system, it will be appreciated that an embodiment of another exemplary branch processing method (in Figure 5 The method (represented as method 104) includes: receiving information from at least two branch execution units (106); writing two updates to corresponding first and second write queues (108) on each clock cycle based on the information; and writing up to two updates from the first write queue to multiple tables (e.g., edges) of a first predictor on each clock cycle, and writing a single update for a single clock cycle in the presence of an expected write conflict, the first predictor including a single write or read / write port (110).

[0065] Any processing description or block in the flowchart should be understood to represent a module, segment, logic or portion of code (which includes one or more executable instructions for implementing specific logical functions or steps in the process), and alternative implementations are included within the scope of the embodiments, where, as those skilled in the art will understand, functions may be performed out of the order shown or discussed (including substantially concurrently or in a different order), depending on the functionality involved.

[0066] Although the present invention has been shown and described in detail in the drawings and the foregoing description, such illustration and description should be considered illustrative or exemplary rather than restrictive; the invention is not limited to the disclosed embodiments. Other variations of the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention from a study of the drawings, the disclosure, and the appended claims.

[0067] Note that different combinations of the disclosed embodiments may be used, and thus reference to an embodiment or one embodiment does not exclude features from that embodiment from being used together with features from other embodiments. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality.

Claims

1. A microprocessor comprising: two branch execution units configured to execute two branches per clock cycle; first write logic and second write logic configured to receive information from the two branch execution units; a first write queue and a second write queue, the first write logic and the second write logic being configured to write two updates to the corresponding first write queue and second write queue in each clock cycle based on the information; as well as a branch predictor comprising a plurality of tables configured to predict a plurality of branches for each instruction cache fetch, the branch predictor comprising a single write or read / write port; The first write queue is configured to write two updates to separate tables of the plurality of tables for a single clock cycle, and to write a single update for a single clock cycle if there is an expected write conflict.

2. The microprocessor of claim 1 , further comprising an additional branch predictor, the additional branch predictor comprising a plurality of tables, the additional branch predictor comprising a single write or read / write port, wherein The second write queue is configured to write two updates to separate ones of the plurality of tables of the other branch predictor for a single clock cycle and, in the event of an expected write conflict, to write a single update for a single clock cycle.

3. The microprocessor according to claim 2, wherein: The branch predictor comprises a branch target address cache or BATC, and the other branch predictors comprise a tag geometry length predictor or TAGE predictor.

4. The microprocessor according to claim 2, wherein: The first write queue and the second write queue are each configured to write updates based on an update opportunity.

5. The microprocessor according to claim 4, wherein: The update opportunity comprises the availability of a write to the branch predictor, or the other branch predictor, or a corresponding table of the branch predictor and the other branch predictor.

6. The microprocessor according to claim 4, wherein: The update opportunities include when one or more of the first write queue and the second write queue are full.

7. The microprocessor according to claim 4, wherein: The update opportunity includes exceeding a predetermined pendency in one or more of the first write queue and the second write queue.

8. The microprocessor according to claim 2, wherein: In the presence of the expected write conflict, the older mispredicted branch instruction is updated relative to the newer mispredicted branch instruction.

9. The microprocessor according to claim 2, wherein: The update includes one or more of a branch target address and a change to a counter.

10. A branch processing method, comprising: Receive information from two branch execution units; writing two updates to the corresponding first write queue and second write queue in each clock cycle based on the information; as well as Two updates are written per clock cycle from the first write queue to multiple tables of a branch predictor, and in the event of an expected write conflict, a single update is written for a single clock cycle, the branch predictor including a single write or read / write port.

11. The branch processing method according to claim 10, further comprising: Two updates are written from the second write queue for a single clock cycle to multiple tables of other branch predictors, and a single update is written for a single clock cycle in the event of an expected write conflict, the other branch predictors including a single write or read / write port.

12. The branch processing method according to claim 11, wherein: The branch predictor includes a branch target address cache or BATC, and the other branch predictors include a tag geometry length predictor or TAGE predictor. 13 . The branch processing method according to claim 11 , further comprising updating from the first write queue and the second write queue based on an update opportunity.

14. The branch processing method according to claim 13, wherein: The update opportunity comprises the availability of a write to the branch predictor, or the other branch predictor, or a corresponding table of the branch predictor and the other branch predictor.

15. The branch processing method according to claim 13, wherein: The update opportunities include when one or more of the first write queue and the second write queue are full.

16. The branch processing method according to claim 13, wherein: The update opportunity includes exceeding a predetermined pendency in one or more of the first write queue and the second write queue.

17. The branch processing method according to claim 11, wherein: In the presence of the expected write conflict, the older mispredicted branch instruction is updated relative to the newer mispredicted branch instruction.

18. The branch processing method according to claim 11, wherein: The update includes one or more of a branch target address and a change to a counter.

Images