Tracking caching techniques based on bias control transfer instructions

Abstract

The disclosed technology relates to a trace cache circuit configured to identify and cache traces that meet certain criteria. The predictive circuitry may track the direction of executed control transfer instructions, including a first category of control transfer instructions (which may be referred to as "stable") that comply with a first threshold bias level toward a given direction, and a second category of control transfer instructions (which may be referred to as "unstable") that do not comply with the first threshold bias level. The trace cache circuit may identify a trace of instructions that satisfy a set of criteria that include allowing only control transfer instructions of a first category as internal control transfer instructions, and allowing control transfer instructions in a second category only at the end of a given trace. The disclosed techniques may advantageously provide performance and power advantages of the tracking cache with reduced complexity relative to certain conventional tracking caches.

Description

Technical Field

[0001] This disclosure relates generally to computer processor architecture, and more specifically to trace cache circuitry. Background Technology

[0002] Description of the Related Art Trace caches store instruction traces, which typically include at least one internal take branch and can terminate within that branch. Trace caches can significantly improve performance by increasing instruction fetch bandwidth (compared to multiple fetches from the instruction cache) and can also reduce fetch power consumption. However, this can be costly when a branch unexpectedly exits the trace cache, and trace caches and their control circuitry can utilize significant processor area and power. These trade-offs have hindered the practical implementation of trace caches in traditional processor designs. Attached Figure Description

[0003] Figure 1 This is a block diagram illustrating an example processor pipeline including a tracking cache according to some implementation schemes.

[0004] Figure 2A This is a diagram illustrating the example branch stability classification based on some implementation schemes.

[0005] Figure 2B This is a diagram illustrating example stable / unstable extraction group locations allowed in the tracking of some implementation schemes.

[0006] Figure 3 This is a diagram illustrating example fields for tracking cache entries according to some implementation schemes.

[0007] Figure 4 This is a block diagram illustrating a more detailed example pipeline based on some implementation schemes.

[0008] Figure 5 This is a block diagram illustrating how to follow up on the next extraction predictor based on some implementation examples.

[0009] Figure 6 This is a block diagram illustrating example pre-hash branch history tokens according to some implementation schemes.

[0010] Figure 7 This is a block diagram illustrating an example tracking prediction channel for a branch predictor with shared resources, according to some implementation schemes.

[0011] Figure 8 This is a block diagram illustrating an example tracking prediction channel for a Tag Geometric Length (TAGE) predictor according to some implementation schemes.

[0012] Figure 9 This is a diagram illustrating example relaxation conditions for allowing less stable control transfer instructions before the end of tracking, according to some implementation schemes.

[0013] Figure 10A This is an example illustration of a filter-based less unstable before end (LBE) tracking cache technique according to some implementation schemes.

[0014] Figure 10B This is another example illustration of a tracking cache entry field according to some implementation schemes.

[0015] Figure 10C This is a diagram illustrating example fields for the next extract predictor entry based on some implementation schemes.

[0016] Figure 11 This is a block diagram illustrating an example pipeline according to some implementation schemes, which includes filter circuitry for training to prevent certain control transfer instructions from being included before the end of tracking.

[0017] Figure 12 This is a diagram illustrating an example control circuit according to some implementation schemes, which enables hits on both the instruction cache and the trace cache for entries in the shared branch predictor table.

[0018] Figure 13 This is a flowchart illustrating example methods for operating a tracking cache according to some implementation schemes.

[0019] Figure 14 This is a flowchart illustrating an example method of utilizing the Less Instable Branch Before End (LBE) according to some implementation schemes.

[0020] Figure 15 This is a flowchart illustrating an example method for operating a follow-up predictor based on some implementation schemes.

[0021] Figure 16 This is a flowchart illustrating an example method for operating a processor with a tracking cache branch predictor channel, according to some implementation schemes.

[0022] Figure 17 This is a block diagram illustrating an example computing device based on some implementation schemes.

[0023] Figure 18 These are illustrations illustrating example applications of systems and devices disclosed according to some implementation schemes.

[0024] Figure 19 This is a block diagram of an example computer-readable medium illustrating storage circuit design information according to some implementation schemes. Detailed Implementation

[0025] Summary and Brief Overview of the Disclosure In the various implementations discussed in detail below, the control circuitry for the tracking cache is configured to assemble the tracking of instructions that conform to certain criteria. For example, the control circuitry may restrict internal conditional branches to "stable" branches that conform to a bias threshold in one direction. An "internal" branch is a branch that is not the last instruction in the tracking. The following sections provide a brief overview of the various disclosed techniques related to stable tracking caches. Figures 1-4 An example implementation of the tracing cache is shown. Figures 5-6 This involves the next fetch predictor configured to combine tracking cache hits with operations. Figures 7-8 The logic for the additional trace cache channel used in the branch predictor is shown. Figures 9-12 This involves allowing for less stable internal branches within the trace in certain scenarios. The remaining figures illustrate example methods, devices, and systems.

[0026] In the disclosed embodiments, the trace cache circuitry is configured to cache only traces with internal control transfer instructions that meet certain criteria. For example, the concept of "stable" branches can improve trace cache performance. Restricting internal branches can advantageously reduce the size of the trace cache required to achieve a given performance level. For example, for a sequence of instructions with branches that are uniformly biased (50% employed and 50% not employed during execution), the trace can be cached for each branch direction to achieve the desired performance. If these traces subsequently include another internal branch that is equally unstable, four traces can be cached, and so on. In contrast, a single trace with multiple stable branches can provide a significant performance improvement even without caching other overlapping traces. Restricting internal branches also increases the likelihood that the entire trace will be executed when a hit exists in the trace cache (as opposed to front-end redirection if any internal branch has a direction different from the expected direction for the trace). Furthermore, restricting internal branches reduces complexity on the processor's critical path. In some embodiments, while only stable branches are allowed as internal branches in a trace, the trace can end on a non-branch instruction, an unstable branch, or a stable branch.

[0027] As used herein, the phrases "stable branch" and "stable control transfer instruction" refer to control circuitry that, based on its execution history, has determined to treat a control transfer instruction as unconditional for a period of time, even if the control transfer instruction might be conditional. In other words, based on its historical execution, some conditional control transfer instructions have been elevated to a "stable" state. In the disclosed embodiments, these control transfer instructions can be predicted based on this state, and the stable state can be a criterion used for inclusion in the trace cache. Specifying conditional control transfer instructions as stable / biased is a form of dynamic prediction that depends on the runtime behavior of the instruction, rather than a static prediction that can be performed independently of instruction execution (e.g., at compile time).

[0028] For example, control circuitry may designate conditional branches that are always adopted (or never adopted) during execution as stable because they are 100% biased during the observed execution period. In some implementations, branches that meet lower thresholds (such as 95%, 98%, 99.5%, etc.) over a certain period are considered stable. In some implementations, once a branch is designated as biased / stable, the bias branch predictor is configured to always predict that those branches will be executed in the direction of the historical bias (e.g., for a branch that is adopted 99% of the time during execution and has been designated as stable by control circuitry, the bias predictor may predict that the branch will be adopted for every execution of the branch under a stable designation). Branch predictions for stable branches typically have a relatively high confidence level.

[0029] In some implementations, control transfer instructions not initially designated as stable may transition to a stable state based on their execution behavior. For example, if a control transfer instruction is a conditional branch instruction that is initially adopted, it may be designated as stable and subsequently considered an unconditionally adopted branch. If, at some later point, the branch instruction is determined not to be adopted during execution, it may transition to an unstable state. In other implementations, other criteria may be used to determine transitions into and out of stable states. For example, the behavior of multiple instances of instruction execution may be considered before transitioning to or out of a stable state. Thus, for the period between when a control transfer instruction is designated as stable and when that designation is removed, the control transfer instruction may be considered unconditional. During this period, other forms of prediction (if available) may not be utilized. Once the control transfer instruction is no longer in a stable state, other types of predictors may be used to predict the instruction's behavior.

[0030] It should be noted that unconditional branches or other unconditional control transfer instructions can be classified and processed as stable based on their properties (rather than dynamically determined to be stable). Therefore, the disclosed techniques can classify all or a subset of the following example instructions as stable: unconditional control transfer instructions (e.g., B or BL instructions), conditional control transfer instructions that satisfy a bias threshold (e.g., CBR instructions), indirect instructions that satisfy a bias threshold (e.g., BR or BLR instructions), and return instructions that satisfy a bias threshold. Conditional instructions, indirect instructions, return instructions, etc., that do not satisfy a bias threshold can be considered unstable.

[0031] As used herein, the phrases “control transfer instruction,” “program flow instruction,” and “branch instruction” are used interchangeably. Such instructions include at least conditional branch instructions, call instructions, return instructions, jump instructions, etc. Additionally, while the term “branch instruction” (or more simply “branch”) may be used throughout this disclosure for convenience, it should be understood that the term applies to any type of control transfer instruction that can be utilized in an instruction set architecture.

[0032] In some embodiments, a separate bias branch predictor provides predictions for bias branches. For example, U.S. Patent Application No. 17 / 590,719, filed February 2, 2022, entitled “Conditional Instructions Prediction,” discusses an example bias branch predictor circuit that can be implemented in the disclosed embodiments. For example, the '719 application discusses a bias table with entries that track whether a given assignment branch is biased over multiple executions of the branch. In other embodiments, stable branches may be predicted by multiple predictors, by a predictor that also provides predictions for unstable branches, or by both.

[0033] For a given branch, the bias branch predictor may have a higher priority than other predictions. In some implementations, the bias branch predictor maintains a field (e.g., a bit) for each branch that indicates whether the branch has deviated from the expected direction during execution. The bias branch predictor may include a training interval before predicting a branch (e.g., such that a given branch must be executed at least a threshold number of times before being predicted as biased). The control circuitry may periodically reset the bias branch predictor at relatively long intervals, so that conditional branches that only very occasionally adopt different directions have a chance to be retrained as biased after the reset.

[0034] As mentioned above, branches meeting a lower bias threshold of less than 100% can be considered stable. For relatively high thresholds, the bias branch predictor can maintain a counter for each branch, indicating the number of times the executed branch does not have the expected direction. When this counter meets a threshold number, the branch can be considered unstable. For lower thresholds (e.g., 95% adopted), this method may utilize a large number of counter bits, and therefore the bias branch predictor can use other representations to encode the ratio of adopted to unadopted branches.

[0035] As an example, to reduce the circuit area and power used for tracking bias, the control circuitry might initially assume all branches meet the bias threshold. However, the control circuitry can implement a usefulness filter to prevent branches that don't actually meet the threshold from being included in the tracking. For example, the control circuitry could maintain a usefulness field and, for a branch exiting a given tracking, reduce that field by a larger amount than increasing the field of branches whose direction remains within the tracking. The filter circuitry can prevent branches that fail to meet the threshold usefulness value from being cached (meaning one or more internal branches fail to meet the bias threshold). For example, the filter circuitry could add those branches to a Bloom filter. The filter can be updated based on cached tracking during training, based on cached tracking in the tracking cache, or both.

[0036] In some implementations, "stable" branches are designated as multiple subcategories that can be processed differently. For example, in certain scenarios or conditions, the control circuitry may allow "Lesserly Unstable Before End" (LBE) branches as internal branches within the trace. There may be restrictions on where less unstable branches are allowed within the trace (e.g., within certain fetch groups). These techniques can improve trace cache coverage and performance with limited trade-offs in size, unexpected trace exits, etc. It should be noted that, similar to the most stable category, branches designated as various stability subcategories can be reclassified based on further execution.

[0037] In some implementations, the next-to-fetch predictor is configured to predict the next fetch address after the trace is performed. The next-to-fetch predictor can be a single-loop predictor. To generate fast predictions, the next-to-fetch predictor can utilize pre-hash branch history tokens based on multiple adopted branches within the corresponding trace (e.g., because generating multiple historical updates for those branches in a single loop may not be feasible).

[0038] In some implementations, certain branch predictor circuitry is shared for tracking-related predictions and other predictions. It should be noted that since tracking can end with an unstable branch, it may be desirable to incorporate that branch into prediction training, predict the direction of that branch, or both. In some implementations, the branch predictor includes a dedicated prediction channel for predicting tracking-ending branches, which can advantageously provide sufficient prediction performance without requiring a separate branch predictor table for tracking-related predictions. For implementations that allow for less unstable internal branches, a given branch predictor table entry and predictor channel can be shared for both instruction cache and tracking cache hits, as referenced below. Figure 12 It was discussed in detail.

[0039] Overview of Example Trace Cache and Bias / Stability Criteria Figure 1 This is a block diagram illustrating an example processor pipeline including a trace cache according to some implementation schemes. In the illustrated example, the pipeline includes trace cache circuitry 110, trace cache tag circuitry 115, instruction cache circuitry 120, instruction cache tag circuitry 125, branch predictor 130, instruction translation back buffer (iTLB) 135, next fetch program counter (PC) multiplexer (MUX) 140, concatenation logic and concatenation queue 150, MUX 155 and decoding circuitry 160.

[0040] In some implementations, trace cache 110 is configured to detect and store traces that include instructions with at least one internal take-up branch. Therefore, a given trace may include multiple basic blocks. A "basic block" is a sequence of instructions with no control incoming except at its entry point and no control outgoing except at its exit point. As discussed above, trace cache 110 may impose various conditions on the trace, such as the type of allowed internal branches, the size of the trace, the number of internal branches taken, the number of fetch groups, etc. In some implementations, trace cache 110 is configured to store traces with multiple internal take-up branches. Trace cache 110 may impose restrictions on internal condition branches (e.g., threshold bias levels as discussed above). Trace cache 110 may cache only traces corresponding to the bias direction of a given internal branch and not traces corresponding to other directions of internal branches.

[0041] In some implementations, the tracking cache tagging circuit 115 is configured to store tag information (e.g., all or part of the corresponding fetch PC) for entries in the tracking cache 110. Fetching a PC that matches a tag enables a hit in the tagging circuit 115 and allows the decoding unit 160 to utilize instructions from the corresponding track in the tracking cache 110 via the MUX 155. It should be noted that various other information can also be used to tag the tracking cache, such as global history, path history, other branch history encodings, etc.

[0042] In some implementations, the splicing logic and splicing queue circuitry 150 are configured to identify traces that meet the conditions for caching in the trace cache 110. Circuitry 150 may also buffer / queue traces until they are ready for caching (e.g., during training intervals). Circuitry 150 may also splice fetch groups to generate a trace for caching. This may include selecting different portions of fetch groups or cache lines from the instruction cache (e.g., portions up to and including the adopted branch, portions starting with the target of the adopted branch, etc.) such that the trace does not include instructions predicted not to be included in the trace. Therefore, the instructions in the trace can be stored sequentially in the trace, even if their program counters may not be sequential.

[0043] In some implementations, circuitry 150 is configured to buffer fetch sets received from instruction cache 120, from which traces are spliced ​​(instead of buffering instructions from trace cache 110). Circuitry 150 may also train candidate traces to determine whether they should be promoted within trace cache 110 (or promoted from a separate buffer to trace cache 110).

[0044] In some implementations, circuit 150 utilizes a rolling window technique to identify tracks. Circuit 150 can impose various constraints on the formed tracks based on various criteria discussed herein. In a rolling window implementation, queuing circuitry can buffer multiple partially overlapping tracks (e.g., one track includes fetch groups A, B, and C, and another track includes fetch groups B, C, and D) and can select from overlapping tracks based on usefulness counters of different tracks to promote them to an active state in track cache 110. (Alternatively, control circuitry can select from overlapping tracks based on various criteria (e.g., earliest first fetch group, etc.). In some implementations, circuitry is configured not to promote overlapping tracks in track cache 110. This can advantageously provide substantial performance benefits associated with cached tracks compared to conventional techniques, while limiting the size of the track cache.

[0045] In the illustrated example, traces are identified after decoding for potential cache in trace cache 110. In other embodiments, traces may be identified earlier in the pipeline. However, later identification allows traces to be less speculative (e.g., because any front-end redirection may have been performed before the trace was formed). Note that in the illustrated example, trace cache 110 stores pre-decoded instructions, but in other embodiments, a similar trace cache may store decoded instructions.

[0046] In some implementations, instruction cache 120 is configured to cache instructions. Cache 120 may store multiple instructions in a given instruction cache line (e.g., corresponding to the fetch set width). In some implementations, instructions are stored sequentially on a given cache line. Therefore, a branch on a given cache line may follow instructions on the next pass path. In contrast, cache trace in trace cache 110 may include instructions on the prediction-taken path immediately following the branch taken by prediction.

[0047] In some implementations, instruction cache tagging circuitry 125 is configured to store tag information (e.g., all or a portion of the fetch set PC) for entries in instruction cache 120. When a hit occurs in both trace cache 110 and instruction cache 120, arbitration circuitry can (e.g., via MUX 155) prioritize the trace cache. It should be noted that in some implementations, a portion of the fetch set PC is also used to index into trace cache 110, instruction cache 120, or both (and the index bits may be the same or different for different caches).

[0048] The control circuitry may temporarily de-energize or otherwise degrade the power / performance state of the instruction cache 120, instruction cache tag circuitry 125, or both in response to a hit in the tracking cache 110. In other embodiments, the instruction cache circuitry may remain energized, for example, to allow further fetching before the end of tracking in the tracking cache.

[0049] In some implementations, iTLB circuitry 135 is configured to store translations from virtual memory space to physical memory space for instruction access. A hit in iTLB 135 allows for faster access to the translation information compared to performing a page traversal to generate a translation on the ground of a miss. In some scenarios, the output of iTLB circuitry 135 can be used to retrieve instructions stored in instruction cache 120, trace cache 110, or both. In the illustrated implementation, trace cache 110 and instruction cache 120 are virtually labeled, but in other implementations, one or both of these caches are physically labeled. The various caches discussed herein may be included in a cache / memory hierarchy comprising one or more higher-level caches and system memory.

[0050] In some embodiments, branch predictor 130 includes circuitry configured to predict the direction of conditional control transfer instructions. In some embodiments, the processor includes multiple branch predictors. Different predictors may be configured to provide predictions in different pipeline stages (e.g., the next fetch predictor may be a single-loop predictor, while other predictors may generate predictions over multiple loops). As briefly mentioned above, in some embodiments, branch predictor 130 is trained based on the results of executed control transfer instructions, including control transfer instructions stored as part of a trace. In embodiments where multiple instructions are fetched in each loop, a given branch predictor 130 may implement multiple channels to provide individual predictions for cases where the fetch group includes multiple conditional control transfer instructions. In some embodiments, branch predictor 130 includes a bias branch predictor configured to provide predictions for bias branches. Reference is made below. Figures 5-8 and Figure 12 This section discusses a detailed example of a branch predictor circuit in the context of tracking the cache.

[0051] In some implementations, the next fetch PC MUX 140 is configured to select the next fetch PC from multiple input options. For example, inputs may include the next sequential PC (e.g., current PC + fetch group size), inputs from multiple branch predictors, etc. In some implementations, arbitration circuitry is configured to control the MUX 140 to select an input when multiple branch predictors provide different predicted fetch PCs. When the fetch PC from the MUX 140 is mispredicted, the instruction can be refreshed and replayed from the misprediction point. Similarly, when an internal control transfer instruction exits the cached trace in the trace cache 110 (in an unexpected direction), the pipeline can be refreshed and replayed from that point.

[0052] In some implementations, the decoding circuit 160 is configured to at least partially decode the fetched instructions provided by the MUX 155. The decoding circuit 160 may be configured to decode multiple instructions from a given set of fetched instructions from a given source in a given loop. The MUX 155 may select to track the output of the tracking cache 110 upon a tracking cache hit.

[0053] It should be noted that multiple critical paths may exist in the illustrated example, such as from branch misprediction to the next extraction PC MUX 140, or from the loop of the next extraction predictor (see below). Figure 4 (Discussion) and input to the next extractor predictor, lookup logic and redirection control based on instruction cache and branch predictor information, writing to the instruction buffer (which may be included between cache 110 / 120 and decoding unit 160, but not explicitly shown), etc. The various disclosed techniques discussed in detail below allow extraction through the first adopted branch without substantially affecting this key path.

[0054] Figure 2A This is a diagram illustrating example stability classifications according to some implementation schemes. It should be noted that in other implementation schemes, more or fewer categories / subcategories may be defined and handled differently. Figure 2A The spectrum of “bias” from never used to always used is shown. As shown, branches that are almost never used or almost always used are designated as stable (the actual threshold can vary, and some implementations may consider only 100% biased branches as stable).

[0055] Branches that are not in the stable category but are still close to one end of the spectrum can still be designated as "less unstable" and can be referenced as follows. Figure 9 Candidates for the Less Unstable End Before (LBE) technique are discussed in detail. In these implementations, branches historically executed within the LBE scope are allowed at one or more locations within the trace (though those locations may be limited). This allows the trace cache to cache more traces relative to more stringent implementations without significantly increasing the trace cache size or the misprediction rate of internal trace branches.

[0056] It should be noted that some implementations may consider only biases in one direction (e.g., bias is employed) to include branches in the trace, while other implementations may consider branches biased in either direction.

[0057] Figure 2BThis is a diagram illustrating example stable / unstable fetch group locations allowed in a tracing according to some implementations. In the illustrated example, the tracing contains N fetch groups. In this implementation, only stable control transfer instructions are internally allowed, while unstable control transfer instructions are allowed to terminate the tracing (but the tracing can also end on another type of instruction, e.g., when the tracing size is reached). As discussed above, this advantageously reduces the possibility of all instructions in a cached tracing not actually being in the correct execution path, compared to specific implementations that do not distinguish between different categories / stabilities of control transfer instructions.

[0058] In some implementations, the processor may implement various standards for tracing construction. For example, in some implementations, a minimum number of adopted branches are required to cache the tracing. Tracing may be allowed to end with a stable or unstable branch, which may be part of the tracing (or the tracing may end with a non-branch instruction). When using the rolling window technique to select from multiple tracings during training, in addition to its usefulness, the size and number of extraction groups for a given tracing can also be considered.

[0059] Figure 3 This is a diagram illustrating example fields of a trace cache entry according to some embodiments. In the illustrated embodiments, a given entry includes a tag field 310 (which may be implemented by circuitry 115), a validity field 320, trace data 330, and a replacement field 340. In some embodiments, the trace cache 110 is directly mapped. In other embodiments, the trace cache 110 is set-associative or fully associative.

[0060] The tag field 310 may include all or part of the first extraction group PC (or, for example, a value derived from it according to a hash function). As discussed above, this field can be used to detect hits in the trace cache 110. In various disclosed embodiments, the extraction group PC is used to access the trace cache 110 (e.g., to generate index and tag information). However, in other embodiments, various additional information, such as global history information, signature information, security information, etc., may be used to access the trace cache.

[0061] The Valid field 320 indicates whether an entry is currently valid. Entries may become invalid for various reasons, such as failure to execute the entire tracing, context switching, consistency requests, or self-modification of code. The Replace field 340 can be used in certain scenarios to select entries for eviction.

[0062] In the illustrated example, trace data 330 includes up to N instructions from up to M fetch groups. It should be noted that in a given implementation, the total number of instructions, the number of fetch groups, or both may be limited. For example, a given implementation may support 2, 3, 4, 5, etc., fetch groups, and up to 8, 16, 32, 64, etc., total instructions in the trace. In some implementations, trace cache entries are configured to store the target of all potentially adopted branches in the trace, which facilitates access to this information if a predicted unadopted branch eventually exits the trace.

[0063] In the illustrated implementation, the substitution field 340 represents information used to facilitate eviction decisions, such as Least Recently Used (LRU) information, usefulness information, etc. A usefulness-based scheme can increase the usefulness value upon successful tracing execution and decrease it based on various factors, such as failure to execute the entire tracing upon hit, decay over time, decay based on the use of other tracings, etc. When a tracing is ready to be promoted to the tracing cache 110 and the corresponding entry is unavailable, the control circuitry can determine whether to stop promoting the tracing or evict the current entry to free up space for the tracing. The substitution field 340 may have default values ​​regarding the allocation of tracing cache entries and can trigger various actions upon reaching one or more thresholds.

[0064] Detailed Example Pipeline Figure 4 This is a block diagram illustrating a more detailed example pipeline according to some implementation schemes. In the illustrated implementation scheme, the processor includes the components referenced above. Figure 1 The various circuits discussed include the next extract predictor 410, other branch predictors 434, stable branch predictor 432, tracking next extract predictor (NFP) 420, and tracking cache training circuit 455.

[0065] In some implementations, trace cache training circuitry 455 is configured to interact with splicing logic and splicing queue 150 to determine when a trace is promoted to trace cache 110. The trace cache training circuitry can enforce various criteria for traces, including the size, type, etc., of internal control transfer instructions. In some implementations, traces being trained are stored in trace cache 110 but marked as "training" until they reach a usefulness / training threshold (in these implementations, the queue circuitry of element 150 may be omitted). In other implementations, trace information for traces being trained may be stored in a separate buffer, such as in circuitry 150. In some implementations, replacement field 340 is a usefulness field used to select from multiple partially overlapping traces for promotion. Generally, traces may be buffered in trace cache 110 or in a separate buffer until they meet a usefulness threshold. At this point, the training circuit 455 may, for example, allocate valid entries for those tracks by moving those tracks to the tracking cache 110, set those tracks to valid / ready in the tracking cache 110 if they are already buffered in the tracking cache entries, and so on.

[0066] In some implementations, the stable branch predictor 432 is configured to provide predictions for branches that meet a bias threshold. In some implementations, for example, because the bias prediction may have a high confidence level, an arbitration circuit (e.g., controlling MUX 140) gives the predictor from predictor 432 a higher priority than one or more other predictors.

[0067] In the illustrated implementation, the processor also includes multiple next-fetch predictors. In the illustrated implementation, if a hit exists in both tables, both the next-fetch predictor 410 and the tracking NFP 420 provide the predicted next-fetch PC to the next-fetch PC MUX 140 in a given loop.

[0068] In some implementations, the next fetch predictor 410 provides a prediction of the next fetch group following the current fetch group. In contrast, the tracking next fetch predictor 420 provides a prediction of the next fetch group after executing the tracking cache 110; therefore, in some scenarios, this next fetch group may be several fetch groups away from the previous fetch group. See below for reference. Figure 5 and Figure 6 A detailed example implementation of the tracking next extraction predictor 420 is discussed.

[0069] In some implementations, the illustrated next-extraction predictor corresponds to different tables within the same next-extraction predictor unit. Different next-extraction predictors may access the tables based on different information (e.g., different parts of the currently extracted PC), with or without historical information, with or without signature technology, etc. In some implementations, tracking next-extraction predictor 420 has the highest priority among multiple next-extraction predictor tables.

[0070] Trace Next Fetch Predictor (tNFP) Generally, a follow-up fetch predictor for a follow-up cache can advantageously provide the next fetch address after the end of the follow-up (which may be several branches away from the current fetch address) to allow the front end to quickly continue fetching the appropriate instructions after a hit in the follow-up cache 110.

[0071] Figure 5 This is a block diagram illustrating an example tracking next-extraction predictor according to some implementation schemes. In the illustrated implementation, the processor includes a next-extraction predictor 410, a tracking next-extraction predictor 420, and a next-extraction PC MUX 140. Predictors 410 and 420 may be referenced above. Figure 4 The configuration is as briefly discussed.

[0072] As shown in the figure, the next extraction predictor 420 is configured to output the predicted PC after a hit in the tracing cache, the predicted PC being several extraction groups away from the current PC. This can advantageously improve front-end extraction bandwidth in the context of successful tracing execution. See below for reference. Figure 6 Discuss example formats for entries in circuit 420.

[0073] The next extraction predictor 410 provides the predicted PC and the next PC in sequence after the current extraction group and the next extraction PC MUX 140 are selected from the outputs of circuits 410 and 420 (but various other inputs to PC MUX 140 are also envisioned). The predicted next PC output of MUX 140 is the input of circuits 410 and 420 for its next prediction.

[0074] In some implementations, for example, since a hit in the next fetch predictor can indicate a hit in the tracking cache 110, the control circuitry is configured to disable reading of the instruction cache tag circuitry 125 and the instruction cache 120 in response to a hit in the tracking next fetch predictor 420.

[0075] It should be noted that providing predictions from the next extract predictor can be challenging in providing correctly updated historical values ​​(e.g., global history, path history, some other historical encoding, or some combination thereof). Figure 6An example technique is provided for pre-compiling information used to generate history, which avoids discarding historical updates (which could reduce predictor accuracy) without negatively impacting the critical path.

[0076] Figure 6 This is a block diagram illustrating an example next-extraction predictor circuit and entry field according to some implementation schemes. In the illustrated example, a given entry in the next-extraction predictor 420 includes a tag 610, the predicted next-extraction address after the corresponding tracking 620 ends, and a pre-hash history token 630. In the illustrated example, the processor also maintains a current history value 640 and includes tag comparison circuitry 650 and hash circuitry 660.

[0077] In the illustrated example, a given entry in the Track Next Extraction Predictor 420 is accessed based on the index portion of the current extraction PC, and a portion of that PC is tagged (field 610). In the illustrated implementation, the tag comparison circuit 650 is configured to indicate a hit or miss in the Track Next Extraction Predictor 420 by comparing one or more tags corresponding to the index (depending on the relevance of the Track Next Extraction Predictor table) with the tag portion of the current extraction PC.

[0078] In some implementations, the index and tag are the same part of the fetch PC used to access the trace cache 110. In some implementations, the next fetch predictor 420 uses fewer tag bits than the trace cache 110 to reduce circuit area. In other implementations, additional information or supplementary information, such as branch history information, may be used to check for hits in the next fetch predictor 420.

[0079] In some implementations, the predicted next fetch address 620 is based on the predicted direction of the tracing end branch, the predicted target of the tracing end branch, or both. If the processor front end wins arbitration at MUX 140, the processor front end can perform various fetch operations (e.g., instruction / trace cache tag checks, etc.) based on this prediction. The tracing next fetch predictor 420 can update this value based on previous executions of the corresponding trace.

[0080] A given entry may also include a validity field, a usefulness field, or both (these fields are in...) Figure 6 (Not shown in the image). The usefulness field can be used to determine when an entry is ready to provide a forecast, when an entry is removed to make room for another forecast, etc., and can be adjusted based on the accuracy / number of forecasts associated with the entry, forecasts based on other valid entries, etc.

[0081] As briefly mentioned above, updating the branch history values ​​used for the next fetch prediction (e.g., within a single loop) can be challenging. Specifically, since a trace may include multiple adopted branches, sequentially hashing multiple values ​​to generate updated history values ​​can have timing effects. Therefore, in some implementations, the trace next fetch predictor may utilize a pre-hashed branch history token 630 based on multiple branches within the corresponding trace. The processor may use multiple XOR and shift operations to compute this value, and the token 630 may be stored in the trace next fetch predictor entry, for example, in response to caching the trace. Token 630 is an example of branch history update information that may be pre-computed based on multiple adopted branches in the trace and provided in response to a predictor hit.

[0082] When the next-branch predictor 420 wins arbitration, the hash circuit 660 is configured to hash the history token 630 using the current history value (which is up-to-date at the hit point in the trace cache 110) to generate the next history value. This next-branch history value can be used to access the predictor table in various predictors, including predictor 420, to generate subsequent predictions.

[0083] In some implementations, there is a one-to-one mapping between stable tracking cache entries and tracking next fetch predictor entries, such that a given stable tracking cache entry corresponds to a single tracking next fetch predictor entry with a prediction for that tracking.

[0084] It's important to note that branch history can be represented using various formulas. The two examples mentioned above are path history and global history. Generally, path history is generated based on the address of the branch used, while global history is generated based on the goal of the branch used. Various implementations can update path history, global history, or both based on the predicted / extracted branches.

[0085] It should be noted that a given branch history update may require hashing a relatively small subset of the bits of the previous value using the new value. Therefore, the size of token 630 can be substantially smaller than the size of the current history value 640, thereby reducing the area of ​​the next-to-fetch predictor table relative to storing the complete updated history value. However, in other embodiments, the next-to-fetch predictor 420 may store a pre-computed, completed updated history value.

[0086] For a given path history update, the hash circuit can be configured to perform an XOR operation between a set of bits from the fetch address of the current fetch group and all or a portion of the bits from the previous path history. As a specific example, the path history can be an M+N bit value, shifted left by one bit and XORed with the N bits of the fetch address of the current fetch group to generate the next path history value in each loop according to the following example equation: path_hist[M+N-1:0] = {path_hist[M+N-2:0], 1'b0} ^ {M'b0, N_bits_of_PC} For a given global history update, the hash circuit can be configured to perform an XOR operation between all or a portion of the branch target and all or a portion of the bits of the previous global history. As a specific instance, the global history can be an X+Y bit value, shifted left by one bit and XORed with the Y bits of the fetch address of the current fetch group to generate the next path history value in each loop according to the following example equation: global_hist[X+Y-1:0] = {global _hist[X+Y-2:0], 1'b0} ^ {X'b0, Y_bits_of_target} It should be noted that the Y bits of the target can be consecutive or non-consecutive, and can be located at different positions within the address in different implementations. The number of bits implemented for M, N, X, Y, etc., may affect the history length used, the control circuit area, the impact of a given address on the current history value, etc. These parameters can vary in different implementations. In other implementations, various other branch history encodings can be implemented.

[0087] Branch Predictor Lane for Trace-Dependent Prediction Generally, various branches associated with tracing can be used to train a branch predictor, which can then predict (e.g., when tracing ends or when fetched from the instruction cache instead of the tracing cache). However, building a dedicated branch predictor for the tracing cache may be undesirable in terms of area and power consumption. Therefore, in some implementations, branch predictor circuitry is shared for tracing-related predictions and other predictions, with some additional circuitry dedicated to tracing-related predictions. For example, predictor tables, program counters, historical data paths, and hash functions may be shared.

[0088] In some implementations, the branch predictor circuit is configured to provide predictions only for the tracking termination branch among all branches in the tracking (but predictions can also be provided for less stable branches before termination, as referenced below). Figure 9(Discussed in detail). In some implementations, updates to stable branches within the tracking are ignored for branch prediction training purposes.

[0089] Figure 7 This is a block diagram illustrating an example trace prediction channel for a branch predictor with shared resources, according to some embodiments. In the illustrated embodiment, the processor includes a trace cache 110, an instruction cache 120, and a branch predictor 710. The trace cache 110 and instruction cache 120 may be configured as described above and may output trace and fetch sets in response to a hit of a fetch address.

[0090] In the illustrated embodiment, branch predictor 710 is configured to provide predictions for one or more control transfer instructions in a given fetch group, and is also configured to provide a prediction for the last control transfer instruction in the trace. In the illustrated embodiment, branch predictor 710 includes one or more shared prediction tables 726.

[0091] As shown in the figure, in addition to the logic 722 for the branch prediction channel used to fetch instructions from the fetch group, the branch predictor 710 also includes dedicated logic for tracking cache channels 724. It should be noted that a given fetch group may include up to N instructions, which may include conditional control transfer instructions located anywhere within the group. Therefore, in the illustrated example, the branch predictor 710 implements N channels to provide individual predictions for different fetch group locations. When some channels do not have conditional branches, these channels may not switch within a given loop. See below for reference. Figure 8 A more detailed example of the channel logic within the Tagged Geometry Length Predictor (TAGE) context is discussed. Note that once a prediction take-off branch is found, the control circuitry can terminate the fetching of the remaining instructions in the group, allowing these instructions to be further processed by the predictor.

[0092] The disclosed implementation can advantageously provide accurate prediction of tracking termination branches with a reasonably small increase in chip area and power consumption by sharing a circuit with other types of predictions. Specifically, internal stable branches may not require the assistance of a branch predictor, so adding a small amount of dedicated circuitry for tracking termination branches may be sufficient.

[0093] In some implementations, the branch predictor 710 is configured to access a shared branch prediction table using the fetch group PC corresponding to the start of the trace and historical values ​​to predict the direction of the trace end control transfer instruction (even if the trace end control transfer instruction is in a fetch group with a different fetch address than the trace start fetch group). While this may not involve updating historical values ​​based on control transfer instructions within the trace, in these implementations it provides sufficient prediction accuracy without requiring hashing to fully update historical values. Specifically, this provides good accuracy due to the stability of internal branches and may not require trace-specific changes to the branch predictor design.

[0094] Figure 8 This is a block diagram illustrating an example tracking prediction channel for a Tag Geometric Length (TAGE) predictor according to some embodiments. In the illustrated example, the TAGE predictor includes a base table T0 810 and M non-base tables 820 (only one non-base table is shown for illustrative purposes). As well understood by those skilled in the art, the TAGE tables are indexed using independent functions of global branch / path history and branch addresses (where the selected branch history lengths form a geometric progression). It should be noted that a variety of numbers of TAGE levels can be implemented in various embodiments. In some embodiments, the TAGE tables are directly mapped. In other embodiments, these tables are associated as a set.

[0095] As shown, the base table is accessed based on all or part of the PC for a given branch. In some implementations, a given base table entry may also include a label (not shown). A given entry in the TAGE base table T0 includes predictions for instructions in the instruction cache fetch set (e.g., an entry for an eight-instruction fetch set would include up to eight predictions). In the illustrated implementation, a given T0 entry includes an additional prediction field for the tracking cache. The T0 table provides one or more branch predictions to the multiplexer (MUX) 840 and a tracking cache prediction to the MUX 845. The MUX 840 and 845 also receive outputs from entries (not shown) in table T1 and are controlled based on whether a hit exists in T1. Generally, the highest-ranking table with hits is used to provide predictions for that channel, while the T0 table is used if all other tables are hits.

[0096] Generally, higher-level tables are indexed based on increasingly larger portions of the global history, combined with the PC (a hash in this example). Tags can also be based on PC, a portion of the global history, its hash, etc.

[0097] In the illustrated example, table M 820 provides MUX 850 and 855 with up to N+1 predictions for the channels in the fetch group plus a tracking cache. These MUXs also receive the output of the MUX used for the previous level TAGE table. Up to N conventional predictions 860 are output from MUX 850, and MUX 855 outputs a tracking cache prediction 865 if a hit exists in any table. In some implementations, for conventional predictions 860, control circuitry may indicate the branch adopted by the first prediction and terminate subsequent predictions.

[0098] As shown in the figure, table M is indexed based on a hash of the program counter and a history generated by hash logic 825 (it can also be labeled using different parts of the PC / history based on similar information). In the illustrated example, each entry has a corresponding label, prediction, position, and usage value. The label value is used to determine a hit or miss at a given index. The prediction value indicates the prediction (e.g., adopt or not adopt) for a valid entry that has a hit. In some implementations, a saturation counter is used to maintain the prediction value, and the prediction value may indicate a specific direction based on a threshold. For example, entries may be considered training entries and may not provide predictions until they reach a threshold.

[0099] The location field indicates the location within the extraction group where the prediction is performed. For example, for an extraction group with N instructions, the prediction can be performed for the first instruction, the second instruction, or the third instruction, and so on.

[0100] In some implementations, fields are used to indicate the usefulness of a given entry. As an example, the table may increase by a specific value when an entry is used to provide forecasts, and decrease over time in response to other events, such as premature exit from tracking or forecasts provided by other tables. Control circuitry may determine when to evict an entry from a given table based on the use of these fields.

[0101] In some implementations, the hit logic 830 determines whether a hit exists based on the label and location fields and passes the prediction fields of the appropriate channels to the MUX 850 and 855. The hit logic also controls the MUX 850 and 855 based on whether a hit exists (e.g., passing a value from the current level based on a hit, or selecting a value from the previous level based on a miss).

[0102] In some implementations, a given entry in the non-base TAGE table includes a "Tracking Cache" field indicating whether the prediction is a tracking cache prediction or an instruction cache prediction. The control circuitry can then provide predictions from entries marked as tracking cache predictions to the MUX 855. The control circuitry can also use the tracking cache field to determine hits and misses (e.g., where the status of the tracking cache field should match the fetch type of the fetch group used for a hit). In these implementations, the control circuitry may ignore the location field used for tracking cache entries.

[0103] In other implementations, the control circuitry is configured to indicate whether an entry is for an instruction cache CTI or a trace CTI. For example, an allocation based on a trace cache trace can use the position of the first instruction in the trace to populate a position field for training, which can be unique (e.g., in an implementation where an unstable branch can only appear after one or more stable branches in the trace, the extraction group PC of the first fetch group will be unique). In this case, since no other branch will use that position, the access associated with the trace will hit the entry. For LBE branches (discussed in detail below), there may be potential aliasing with branch predictor entries in the instruction cache. In some implementations, this can be avoided, for example, by restricting LBE branches so that they cannot be the first instruction of the first fetch group in the trace, inverting the tag bits of the trace cache entries used in the branch predictor (e.g., XORing with a vector of binary 1s), etc.

[0104] In the illustrated example, the additional prediction fields in the entries of table T0 used for tracking the cache, as well as MUX845 and 855, are used for... Figure 7 This is an example of the logic for the tracing cache channel 724, while Tables 1 to N are shared for the traditional instruction cache prediction and tracing cache prediction TAGE predictors.

[0105] Although this paper discusses TAGE predictors for illustrative purposes, the disclosed techniques, which have some dedicated tracking predictor circuitry and other shared circuitry, can be implemented in a variety of other types of branch predictors; Figure 8 The examples provided are not intended to limit the scope of this disclosure. Similarly, while shared predictor resources for tracking cache predictions have been discussed with reference to various embodiments, separate predictors for tracking cache predictions may be implemented in other embodiments.

[0106] Look-Before-End (LBE) Technique As briefly mentioned above, branch predictor circuits can provide predictions for branches of stability across multiple different categories. For example, Figure 2AThe stable portion of the spectrum can be one category, and the LBE candidate portion can be another category (both different from the unstable category that does not meet either threshold). The predictions associated with the stability of different categories can be provided by different predictors (e.g., stable branch predictor 432 and a separate LBE predictor) or by the same predictor (e.g., stable branch predictor 432).

[0107] In some implementations, one or more less stable categories are allowed as non-terminating instructions for tracing in certain scenarios. Generally, the disclosed techniques that allow tracing to contain LBE branches can permit the formation of more tracing than in more restrictive implementations or patterns (e.g., allowing only 100% biased internal branches), which can improve tracing cache coverage while limiting the performance penalty associated with unstable branches.

[0108] Therefore, in some implementations, the tracking forming control circuit (e.g., circuit 150, 455, or both) may include some less stable branches within the tracking. Figure 9 This is a diagram illustrating the concept. As shown, the tracking includes N extraction groups, and one or more less stable control transfer commands are allowed in the middle of the tracking. In some embodiments, a threshold number of less stable branches (e.g., a single LBE branch, two LBE branches, etc.) are allowed in the middle of the tracking. In some embodiments, such less stable branches are restricted to one or more specific locations within the tracking (e.g., extraction group locations).

[0109] When a branch unexpectedly exits the cache trace, the processor can split the retrieved fetch set (to discard instructions following the branch) and redirect the front end to the correct path. Note that unexpected trace exits can occur due to the actual execution of branch instructions in directions where subsequent instructions are not cached in the trace (e.g., when the trace stores instructions that assume the branch is taken, but the branch is not taken). Unexpected trace exits can also occur based on branch prediction before the branch is actually executed. For example, when the trace stores subsequent instructions from the taken path, the processor can split the fetch set from the trace based on the branch predictor's prediction that the branch was not taken.

[0110] In some implementations, the tracing cache 110 is configured to store traces that have only one predicted direction (e.g., the adopted direction) for a given branch, and not to store traces in which the branch is predicted to be executed in another direction.

[0111] In different implementations, the control or prediction circuitry may use different techniques to track the stability of less stable branches. As an example, the control circuitry may count the number of times a given branch is executed in the non-biased direction (e.g., not executing branches that are biased). As another example, the control circuitry may track the overall ratio or percentage of executions of a given branch that were previously executed. However, this can utilize a large amount of storage on a per-branch basis.

[0112] Therefore, in some implementations, the control circuit is configured to assume that branches that do not meet the higher stability threshold still meet the less stable stability threshold (possibly unaware of their stability), but if these branches do not meet this assumption, filtering is performed to prevent such branches from being cached in the trace.

[0113] Figure 10A This is a flowchart illustrating an example of a filter-based LBE technique according to some embodiments. In the illustrated embodiment, at 1002, the control circuitry constructs a track with up to N LBE candidates. This may include storing instructions for tracking in a training buffer or a tracking cache 110. In some embodiments, N=1, and at most a single LBE branch is allowed within the track. In some embodiments, the location of the LBE branch is restricted within the track, for example, restricted to a first extraction group within the track or some other location. It should be noted that in some embodiments, branches meeting a higher stability threshold may be included without such restrictions.

[0114] In the illustrated implementation, at 1004, the control circuit tracks the usefulness of the tracking. This may include incrementing a counter in response to execution of a branch moving toward the next part of the stored tracking, and decrementing the counter in response to execution of a branch moving away from the next part of the tracking (exiting the tracking). The decrement may be greater than the increment (e.g., twice the increment, three times the increment, etc.).

[0115] It should be noted that the usefulness field can also be adjusted based on other factors, such as making the usefulness field decrease over time. In various specific implementations, the usefulness field will ultimately reflect the bias of one or more LBE branches within the track. In some implementations, a separate field can be used to reflect replacement strategy information and LBE usefulness.

[0116] In the illustrated implementation, at 1006, the usefulness value drops below a threshold. In response, the control circuit invalidates the tracking. The control circuit also adds one or more LBE candidate branches to the Bloom filter to prevent one or more LBE candidate branches from being included in subsequent tracking. In these implementations, the filter implements a minimum LBE stability threshold. It should be noted that the upper usefulness threshold for successfully training the tracking and the lower threshold for invalidating the tracking can be different distances from the initial value of the usefulness field. Therefore, in various LBE implementations, tracking can be invalidated faster based on unexpected LBE directions than they are considered to be trained, for example, to avoid the performance impact of branches that do not meet the LBE bias threshold.

[0117] For example, a branched PC or a PC that includes a group of branches can be used to access the Bloom filter. Therefore, the control circuitry can check the Bloom filter before including a given branch as an internal branch within the trace, to prevent the use of branches from the Bloom filter within the trace. While the Bloom filter has been discussed for illustrative purposes, other types of filters can be implemented in other embodiments.

[0118] Figure 10B This is a diagram illustrating example fields of trace cache entries that support LBE according to some implementation schemes. In the illustrated example, in addition to the references above... Figure 3 In addition to the fields 310, 320, and 330 discussed, the tracking cache entries also include the LBE field 1010, the location field 1020, and the usefulness field 1040. It should be noted that these fields may be included in the training buffer, the tracking cache entries, or both.

[0119] In some implementations, the LBE field 1010 indicates whether a trace includes an LBE branch. Some traces may include only the branch with the highest stability category, and field 1010 may not be set for those traces.

[0120] In some implementations, the location field 1020 indicates the position of the LBE branch within the track (e.g., the Nth instruction position). It should be noted that even if the position of the LBE branch is restricted to within the track at a specific granularity (e.g., within the first extraction group), the instruction position of the LBE can still vary. The location field 1020 provides this information. The location field 1020 can facilitate (e.g., from the branch predictor 710) the retrieval of the branch prediction of the LBE branch, and can allow the identification of instructions that will be invalidated to split the extraction group, or both, as discussed in detail below.

[0121] In some implementations, the usefulness field 1040 indicates the usefulness of a given tracking. This can be tracked during training, effectively cached in the tracking cache 110, or both. As discussed above, in some implementations, the usefulness field is decremented by a larger amount when the LBE branch is executed in the non-bias direction compared to when the tracking is fully executed. This allows for tracking invalidation and updates to the Bloom filter for branches whose results do not meet the LBE stability threshold. In some implementations, the usefulness field 1040 is updated differently depending on whether the LBE field 1010 is set.

[0122] In some implementations, a given trace can include multiple LBE branches. In these implementations, the usefulness field can encode separate information for different LBE branches, for example, to indicate a subset of LBE branches that contribute to the trace falling below a usefulness threshold. This allows one or more LBE branches from a trace to be added to a Bloom filter, while other LBE branches remain valid to be included in other traces.

[0123] Figure 10C This is a diagram illustrating example fields of a tracking NFP entry supporting LBE according to some implementations. In the illustrated example, a given NFP entry includes an LBE prediction field 1012 indicating the prediction direction of an LBE branch. In some implementations, the control circuitry uses this field to improve performance when an LBE branch exits tracking.

[0124] For example, consider a case where the trace including the LBE-adopted branch is successfully constructed and useful. Occasionally, the LBE branch may not be adopted multiple times consecutively. However, the number of times may not be sufficient for the usefulness value to decrease to the point where the trace becomes invalid. In this case, in response to the first non-adopted LBE branch, the control circuitry splits the extraction group and redirects the front end. In some embodiments, the control circuitry also trains the tracer next extraction predictor 420 to set the predicted PC (field 620) to the PC of the LBE branch + instruction size (to indicate the sequential instructions following the LBE branch) and sets the LBE prediction field 1012. The next time the LBE branch is not adopted, the tracer NFP 420 provides the sequential next extraction PC. In some embodiments, the control circuitry is aware that the LBE prediction field 1012 is set and does not update the global history, allowing the next extraction group to obtain the correct history. In this way, the processor can avoid front end redirection for one or more subsequent iterations of an unadopted LBE branch. The control circuit can clear the LBE prediction field 1012 in response to the LBE branch taking its expected direction and reset the predicted next fetch address 620 to the end of tracking.

[0125] Figure 11This is a block diagram illustrating an example pipeline according to some implementation schemes, which includes filter circuitry configured to be trained to prevent certain control transfer instructions from being included before the end of tracking. Various components with similar numbering can be referenced as above. Figure 1 , Figure 4 Configure as described in either case, without referring to... Figure 11 These components will be discussed in detail. In the illustrated embodiment, the processor includes an LBE training filter 1110 located between the tracking cache training circuit 455 and the tracking cache 110.

[0126] In some implementations, the LBE training filter 1110 is configured to set Bloom filter entries for LBE branches that cause the tracking to fall below a usefulness threshold. The Bloom filter can be accessed using a PC for the LBE branch, a PC that includes an extraction group of LBE branches, etc. In implementations that allow multiple LBEs in a given tracking, the LBE training filter 1110 can determine which LBEs cause usefulness problems and write them into the Bloom filter accordingly. In some implementations, the LBE training filter 1110 is configured to periodically (e.g., every N million cycles) clear the Bloom filter. Periodic clearing allows certain branches to be included in the tracking again, for example, if anomalies cause them to fall below a bias threshold, but they typically meet a deviation threshold during execution.

[0127] Consider an example with a 50% bias branch. The control circuit might initially assume the branch conforms to the LBE bias threshold. Based on this assumption, tracking in one or both directions with the branch can be used during training or cached in a tracking cache. However, since the assumption is incorrect in this example, one or both tracking will drop below the usefulness threshold, and the branch will be added to the Bloom filter.

[0128] It should be noted that when an LBE branch unexpectedly exits the tracing, the processor may need to restore the global history. In an implementation where LBE branches are allowed only in the first extraction group of the tracing, the processor may simply reset the history to the value corresponding to the start of the tracing. In other implementations, the processor may include more complex logic to store previous historical values ​​corresponding to different LBE locations or perform reverse computation to regenerate the history before the mispredicted LBE branch.

[0129] Example Branch Prediction for LBE Branches Figure 12This is a diagram illustrating an example control circuit according to some implementation schemes, which enables hits on shared branch predictor table entries in both the instruction cache and the trace cache. In this example, LBE branches and trace termination branches are treated differently in terms of branch prediction. Specifically, as referenced above... Figure 7 As discussed in detail, the branch predictor may include additional channels for unstable trace termination branches. In contrast, LBE branches can share the same branch predictor entry and prediction channel for both instruction cache hits and trace cache hits, as discussed in detail below. It should be noted that sharing branch predictor entries for instruction cache hits and LBE entries can be restricted to LBEs in certain locations (e.g., LBEs in the first fetch group of a given trace), while other LBE branches can be assigned their own branch predictor entries.

[0130] In the illustrated example, the MUX 1210 from Figure 8 The MUX 850 receives prediction channel outputs, and the MUX may include N prediction channels for fetch groups of N instructions. Note that in this example, the same entry from one of the TAGE prediction tables (where a trace hit includes an LBE branch) can be used for both instruction cache and trace cache hits. For trace cache hits, in this example, control circuitry (e.g., based on location field 1020) controls the MUX 1210 to select the appropriate prediction for the LBE branch.

[0131] As shown in the figure, the branch predictor can also provide prediction of unstable tracking termination CTI from the MUX 855 in parallel with LBE branch prediction. Generally, the disclosed techniques facilitate LBE branch prediction by sharing existing circuitry, which can limit area and power consumption and prevent capacity stress on the predictor table due to LBE branching, with only a minor reduction in coverage. As discussed above, if the prediction of the LBE branch indicates that tracking has unexpectedly exited, the control circuitry can split the tracking and redirect the front end.

[0132] It should be noted that in some implementations, various disclosed branch predictor techniques (such as dedicated trace cache channels, prediction of trace-ending branches based on the extract program counter of the first extract group of traces, etc.) may be included in multiple separate branch predictors (e.g., separate predictors for direct branches and indirect branches).

[0133] Example Method Figure 13 This is a flowchart illustrating an example method for caching traces according to some implementation schemes. Figure 13The methods shown can be used in conjunction with any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0134] At 1310, in the illustrated embodiment, the processor (e.g., one or more branch predictors) tracks the direction of executed control transfer instructions, which include: control transfer instructions of a first category (e.g., stable branch, LBE branch, or both) that conform to a first threshold bias level toward a given direction, and control transfer instructions of a second category (e.g., unstable branch) that do not conform to the first threshold bias level.

[0135] In some implementations, the first category includes only control transfer instructions that are always adopted in a given direction during execution over a time period (with 100% bias during that time period). In some implementations, the first category includes control transfer instructions that are adopted in a given direction at least at a threshold ratio over a time period. In some implementations, the prediction circuitry includes a bias predictor configured to generate predictions for the first category based on a bias table.

[0136] The first category may include bias ranges of multiple subcategories that are processed differently, for example, in an LBE implementation. For instance, the filter control circuitry may be configured to process a third category of control transfer commands that do not conform to a second threshold bias level (e.g., Figure 2A The processing may include: for a given internal control transfer instruction of the third category in the stored trace, adjusting (e.g., increasing) a counter in a first direction in response to the given control transfer instruction being executed toward the next portion of the stored trace, and adjusting (e.g., decreasing) the counter in a second direction in response to the given control transfer instruction being executed away from the next portion of the stored trace. In response to the counter reaching a threshold in the second direction (e.g., corresponding to the LBE lower limit threshold), the filter control circuitry may prevent the given control transfer instruction from being included in the trace cache as an internal instruction of the trace.

[0137] At 1320, in the illustrated embodiment, the processor (e.g., trace cache control circuitry) identifies traces of instructions that satisfy a set of criteria, which include: a given trace includes at least one internally employed control transfer instruction; conditional control transfer instructions are allowed as internal trace instructions only if they meet a threshold bias level (e.g., only control transfer instructions of the first category may be allowed internally in a trace); and control transfer instructions of the second category are allowed only at the end of a given trace. A given trace may also include up to a threshold number of employed control transfer instructions.

[0138] In some implementations, the concatenation queue circuit is configured to generate traces for caching in the tracking cache circuit based on multiple fetch groups retrieved from the instruction cache. In some implementations, the training circuit for the tracking cache circuit is configured to: buffer traces until they meet a usefulness threshold, and validate entries in the tracking cache circuit for traces that meet one or more criteria and usefulness thresholds (note that this validation may include, for example, allocating new entries in the tracking cache or validating previous entries from training). In some implementations, the training circuit is also configured to: implement a rolling window buffer that buffers multiple partially overlapping traces, and select one of the partially overlapping traces for allocation in the tracking cache circuit based on the usefulness value of the partially overlapping traces. In some implementations, the training circuit is configured to buffer fetch groups retrieved from the instruction cache and is configured not to buffer fetch groups retrieved from the tracking cache circuit (in other words, in these implementations, the traces originate from the instruction cache, not other traces). In some implementations, the training circuit is configured to identify traces of instructions that satisfy that set of cache criteria after the decoding phase of the processor circuitry.

[0139] At 1320, in the illustrated implementation, the processor (e.g., a trace cache) stores one or more identified traces. The processor may retrieve and execute a trace in response to a subsequent hit (e.g., instead of fetching it from an instruction cache).

[0140] In some implementations, the trace cache control circuitry is configured to evict a trace from the trace cache circuitry and replace the trace in the trace cache circuitry with another trace according to a replacement strategy. Generally, the control circuitry can perform various appropriate cache maintenance operations on the trace cache.

[0141] Figure 14 This is a flowchart illustrating an example method for a fetch predictor to perform a follow-up cache hit operation, according to some implementation schemes. Figure 14The methods shown can be used in conjunction with any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0142] At 1410, in the illustrated implementation, the processor (e.g., one or more branch predictors) predicts the direction of control transfer instructions based on branch history values.

[0143] At 1420, in the illustrated implementation, the processor (e.g., a trace cache) identifies and stores the trace of instructions based on the predicted direction of one or more control transfer instructions.

[0144] At 1430, in the illustrated embodiment, the processor (e.g., a trace-next-fetch predictor) predicts the next fetch address based on the current fetch address, including predicting the next fetch address after executing a first trace stored in the trace cache circuitry. In this example, the first trace includes multiple fetch groups and multiple control transfer instructions employed. In some embodiments, the trace includes multiple fetch groups.

[0145] In some implementations, the control circuitry is configured to pre-compute branch history update information based on a plurality of adopted control transfer instructions in a first trace, store the branch history update information in a trace-next-extraction predictor circuit, and retrieve the branch history update information in response to a hit in the trace-next-extraction predictor circuit. The control circuitry may hash the retrieved branch history update information with the current branch history value to generate an updated branch history value. Pre-computation may include performing one or more hash operations on address information associated with a given adopted branch and performing one or more left offset operations. The stored branch history update information may be decoded using fewer bits than the current branch history value.

[0146] In some implementations, at least a portion of the same bit set of the current fetch address is used to index and label the tracking cache circuitry and the tracking next fetch predictor circuitry. In some implementations, the processor includes a non-tracking next fetch predictor circuitry configured to predict the next fetch address based on the current fetch address. Control circuitry may select the prediction performed by the tracking next fetch predictor circuitry in response to a hit between the tracking next fetch predictor circuitry and the non-tracking next fetch predictor circuitry. In other implementations, the control circuitry may implement various arbitration schemes in which the tracking next fetch predictor is given greater weight, higher priority, etc., relative to other next fetch predictors. In some implementations, the tracking next fetch predictor is a single-loop predictor configured to predict the next fetch address for the loop immediately following the loop in which a fetch is performed using the current fetch address.

[0147] Figure 15 This is a flowchart illustrating an example method for utilizing a tracking predictor channel with a shared predictor table, according to some implementation schemes. Figure 15 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0148] At 1510, in the illustrated implementation, the processor executes instructions (including control transfer instructions (CTI)).

[0149] At 1520, in the illustrated implementation, the processor (e.g., the fetch stage) fetches a set of multiple instructions for the processor circuitry in a given clock cycle.

[0150] At 1530, in the illustrated implementation, the processor identifies and stores an instruction trace that includes multiple predicted control transfer instructions.

[0151] At 1540, in the illustrated implementation, the processor (e.g., a branch predictor) stores a prediction table. This table can be shared by predictors for instruction cache hits and trace cache hits, as discussed in detail below. The processor may include multiple predictors, and a given predictor may implement multiple tables.

[0152] In some implementations, the table circuitry includes a field for one or more entries indicating whether those entries are used for tracking cache prediction or for non-tracking prediction. In other implementations, the prediction circuitry may indicate whether an entry is used for tracking cache prediction. For example, the prediction circuitry may use a fixed location value for predictions to the tracking cache circuitry to avoid overlap with non-tracking predictions. The fixed location value may correspond to the start instruction of a cached tracking cache.

[0153] The table circuitry can store multiple prediction tables, such as a base table and multiple levels of Tag Geometry Length (TAGE) tables. The tracking predictor channel circuitry can be configured to use dedicated prediction fields from one or more entries in the base table and share the TAGE table with the CTI predictor channel circuitry. The selection circuitry can generate tracking cache predictions based on hit results from multiple TAGE tables (and can prioritize the highest-level tables).

[0154] At 1550, in the illustrated implementation, the processor accesses a prediction table to predict the direction of multiple control transfer instructions in a given fetch group.

[0155] At 1560, in the illustrated implementation, the processor accesses the prediction table to predict the direction of the final control transfer instruction in the trace cached by the trace cache circuitry. In some implementations, the trace predictor channel circuitry is configured to access the table circuitry using the fetch address associated with the starting fetch group in a given trace to predict the address of the control transfer instruction in the last fetch group in the given trace. This can reduce complexity (e.g., due to the stability of any internal branches in the trace) while providing accurate results.

[0156] It should be noted that Figure 15 The technique for tracking the termination branch can be performed in parallel with the prediction of the LBE branch. For example, for a first control transfer instruction included in the tracking as a non-terminating control transfer instruction, the prediction circuitry can share table entries and CTI predictor channel circuitry for both the tracking (e.g., LBE) prediction and the non-tracking prediction of the first control transfer instruction. For the tracking prediction of the first control transfer instruction, the prediction circuitry can determine the shared CTI predictor channel circuitry based on the position of the first control transfer instruction in the tracking.

[0157] Figure 16 This is a flowchart illustrating an example method for handling LBE branches according to some implementation schemes. Figure 16The methods shown can be used in conjunction with any of the computer circuits, systems, devices, elements, or components disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than shown, or may be omitted. Additional method elements may also be executed as needed.

[0158] At 1610, in the illustrated implementation, the processor (e.g., a branch predictor) predicts the direction of control transfer instructions.

[0159] At 1620, in the illustrated implementation, the processor (e.g., a trace cache) identifies and stores traces of instructions that satisfy one or more criteria, the one or more criteria including that a given trace includes at least one internally employed control transfer instruction.

[0160] In some implementations, one or more criteria further include allowing only a first category of control transfer instructions (e.g., stable branches) at one or more locations within a given track (where the first category of control transfer instructions conforms to a first threshold bias level toward a given direction, and a second category of control transfer instructions does not conform to the first threshold bias level). In some implementations, a second category of control transfer instructions (e.g., LBE branches) is allowed only at one or more other locations within a given track. In other words, LBE branches may be allowed only at certain internal locations, while stable branches may be allowed at other internal tracking locations. It should be noted that stable branches, LBE branches, or unstable branches may be allowed to terminate tracking.

[0161] In some implementations, a given entry in the trace cache circuitry includes a field indicating whether the trace contains a non-terminating control transfer instruction of the second category. In some implementations, a given entry in the trace cache circuitry includes a field indicating the location of a non-terminating control transfer instruction of the second category within the trace.

[0162] At 1630, in the illustrated embodiment, for a given internal control transfer instruction in a trace stored in the trace cache circuit, the processor (e.g., the trace cache control circuit) adjusts a counter in a first direction (e.g., increases the usefulness value) in response to the given control transfer instruction being executed toward the next portion of the stored trace, and adjusts the counter in a second direction (e.g., decreases the usefulness value) in response to the given control transfer instruction being executed away from the next portion of the stored trace.

[0163] In some implementations, the processor adjusts the counter in the second direction by a larger amount than in the first direction.

[0164] At 1640, in the illustrated embodiment, in response to the counter reaching a threshold in the second direction, the processor (e.g., filter control circuitry) prevents a given control transfer instruction from being included in the trace cache as an internal instruction of the trace. In some embodiments, to prevent the inclusion of a given control transfer instruction, the filter control circuitry is configured to access the Bloom filter using the program counter associated with the given control transfer instruction. In some embodiments, the filter control circuitry is configured to periodically clear the Bloom filter.

[0165] In some implementations, in response to the determined direction of a non-terminating control transfer instruction exiting tracking, the processor is configured to discard one or more subsequent instructions in the fetch group including the non-terminating control transfer instruction, and redirect the front-end circuitry of the processor circuitry to fetch other instructions (this may be referred to as splitting and redirection). It should be noted that the determined direction may be based on the actual execution of the non-terminating control transfer instruction, or on the branch predictor's prediction that the non-terminating control transfer instruction will exit tracking. In the latter case, in the rare instance where the branch predictor determines an incorrect direction, the processor may refresh and replay based on the misprediction.

[0166] In some implementations, the prediction circuitry is configured to target shared prediction table entries and prediction channel circuitry for both the instruction cache and the trace cache hits. The selection circuitry can select the prediction channel output from the prediction circuitry based on the location of the corresponding control transfer instruction within the trace.

[0167] The following numbered clauses list the various non-restrictive embodiments disclosed herein: Set A A1. An apparatus comprising: A processor circuit configured to execute control transfer instructions; A prediction circuit is configured to track the direction of an executed control transfer instruction, the control transfer instruction including: A first category of control transfer instructions, wherein the first category of control transfer instructions conforms to a first threshold bias level toward a given direction; and The second category of control transfer instructions does not conform to the first threshold bias level; The tracking cache circuit is configured to: The tracking of instructions that identify compliance with a set of criteria includes: A given trace includes at least one internal control transfer instruction; The conditional control transfer instruction is only allowed as an internal tracking instruction if it meets a threshold bias level; and Control transfer instructions in the second category are only allowed at the end of a given tracking period; and Store one or more identified traces.

[0168] A2. The apparatus according to any of the foregoing provisions in set A, wherein the first category includes only the control transfer instructions in the given direction that are always employed during execution over a period of time.

[0169] A3. The apparatus according to any of the foregoing clauses in set A, wherein the first category includes a control transfer instruction in the given direction at least at a threshold ratio over a period of time.

[0170] A4. The apparatus according to any of the foregoing provisions in set A, the apparatus further comprising: A filter control circuit, configured to process a third category of control transfer instructions corresponding to a subset of the first category of control transfer instructions that do not meet a second threshold bias level, includes being configured to: For a given internal control transfer instruction of the third category in the stored trace, a counter is adjusted in a first direction in response to execution of the given control transfer instruction toward the next portion of the stored trace, and the counter is adjusted in a second direction in response to execution of the given control transfer instruction away from the next portion of the stored trace; and In response to the counter reaching a threshold in the second direction, the given control transfer instruction is prevented from being included in the tracking cache as an internal tracking instruction.

[0171] A5. An apparatus according to any of the foregoing clauses in set A, wherein the prediction circuitry includes a bias predictor configured to generate a prediction for the first category based on a bias table.

[0172] A6. The apparatus according to any of the foregoing provisions in set A, the apparatus further comprising: A splicing queue circuit is configured to generate a trace for caching in the tracking cache circuit based on multiple fetch groups retrieved from the instruction cache.

[0173] A7. The apparatus according to any of the foregoing provisions in set A, the apparatus further comprising: A training circuit for the tracking cache circuit, wherein the training circuit is configured to: The tracking is buffered until it meets a usefulness threshold; and The entries in the tracking cache circuit are verified for tracking that meets one or more criteria and the said usefulness threshold.

[0174] A8. The apparatus according to clause A7, wherein the training circuit is further configured to: Implement a scroll window buffer, in which multiple partially overlapping tracks are buffered; and One of the partially overlapping tracks is selected based on the usefulness value of the partially overlapping tracks for allocation in the tracking cache circuit.

[0175] A9. The apparatus according to clause A8, wherein the training circuit is configured to buffer fetch sets retrieved from the instruction cache and is configured not to buffer fetch sets retrieved from the tracking cache circuit.

[0176] A10. An apparatus according to any of the foregoing provisions in set A, wherein the trace cache circuitry is configured to identify the trace of instructions satisfying a set of standard caches after the decoding phase of the processor circuitry.

[0177] A11. The apparatus according to any of the foregoing provisions in set A, the apparatus further comprising: A tracking cache control circuit, wherein the tracking cache control circuit is configured to: Eject the trace from the trace cache circuit; and The replacement strategy utilizes another trace to replace the trace in the trace cache circuit.

[0178] A12. The apparatus according to any of the foregoing provisions in set A, the apparatus further comprising: A single-cycle next-fetch predictor circuit is configured to predict the next fetch address after tracking in response to a hit in the tracking cache circuit.

[0179] A13. The apparatus according to any of the foregoing clauses in set A, wherein the prediction circuitry comprises: A shared table circuit, configured to store a prediction table; CTI predictor channel circuitry, configured to access the prediction table to predict the direction of multiple control transfer instructions in a given extraction group; and A tracking predictor channel circuit is configured to access the prediction table to predict the direction of a tracking end control transfer instruction in the tracking cached by the tracking cache circuit.

[0180] A14. An apparatus according to any of the foregoing clauses in set A, wherein said apparatus is a computing device, said computing device further comprising: Central processing unit; Displays; and Network interface circuit.

[0181] A15. A method comprising any combination of operations performed by means of any of the foregoing provisions within set A.

[0182] A16. A non-transitory computer-readable medium storing instructions of a hardware description programming language, which, when processed by a computing system, program the computing system to generate a computer simulation model, wherein the model represents hardware circuitry comprising: Any combination of any of the elements described in the preceding clauses within set A.

[0183] A17. A non-transitory computer-readable storage medium storing program instructions that are executable to perform any combination of operations performed by any of the means described in the preceding clauses of set A.

[0184] Set B B1. An apparatus comprising: A processor circuit configured to execute control transfer instructions; Prediction circuit, the prediction circuit being configured to predict the direction of control transfer commands; A trace cache circuit, configured to identify and store traces of instructions that satisfy one or more criteria, the one or more criteria including that a given trace includes at least one internal control transfer instruction; and Filter control circuit, the filter control circuit being configured to: For a given internal control transfer instruction in the trace stored in the trace cache circuit, a counter is adjusted in a first direction in response to execution of the given control transfer instruction toward the next portion of the stored trace, and the counter is adjusted in a second direction in response to execution of the given control transfer instruction away from the next portion of the stored trace; and In response to the counter reaching a threshold in the second direction, the given control transfer instruction is prevented from being included in the tracking cache as an internal tracking instruction.

[0185] B2. The device according to clause B1, the device further comprising control circuitry configured to: In response to the determined direction of a non-terminating control transfer instruction to exit tracking, one or more subsequent instructions in the fetch group including the non-terminating control transfer instruction are discarded, and the front-end circuitry of the processor circuitry is redirected to fetch other instructions.

[0186] B3. The apparatus according to any of the foregoing provisions of set B, wherein said one or more criteria further include: Only a first category of control transfer commands is allowed at one or more locations within a given tracking range, wherein the first category of control transfer commands conforms to a first threshold bias level toward a given direction, and a second category of control transfer commands does not conform to the first threshold bias level; and The second category of control transfer commands is permitted only at one or more other locations within the given track.

[0187] B4. The apparatus according to clause B3, wherein a given entry in the trace cache circuitry includes a field indicating whether the trace has a non-terminating control transfer instruction of the second category.

[0188] B5. The apparatus according to clause B4, wherein a given entry in the tracking cache circuitry includes a field indicating the location of the non-terminating control transfer instruction in the second category within the tracking.

[0189] B6. An apparatus according to any of the foregoing clauses in set B, wherein: The filter control circuit is configured to adjust the counter by a larger amount in the second direction than in the first direction.

[0190] B7. The apparatus according to any of the foregoing provisions in set B, the apparatus further comprising: Instruction cache; in: The prediction circuitry is configured to target shared prediction table entries and prediction channel circuitry for instruction cache and trace cache hits; and The device includes a selection circuit configured to select a prediction channel output from the prediction circuit based on the position of the corresponding control transfer command within the tracking.

[0191] B8. A device according to any of the foregoing clauses in set B, wherein: To prevent the inclusion of the given control transfer instruction, the filter control circuitry is configured to access the Bloom filter using a program counter associated with the given control transfer instruction; and The filter control circuit is configured to periodically clear the Bloom filter.

[0192] B9. A method comprising any combination of operations performed by means of any of the foregoing provisions within set A.

[0193] B10. A non-transitory computer-readable medium storing instructions of a hardware description programming language, which, when processed by a computing system, program the computing system to generate a computer simulation model, wherein the model represents hardware circuitry comprising: Any combination of any of the elements described in the preceding clauses within set B.

[0194] B11. A non-transitory computer-readable storage medium storing program instructions that are executable to perform any combination of operations performed by any of the means described in the preceding clauses of set B.

[0195] Set C C1. An apparatus comprising: A processor circuit configured to execute control transfer instructions; Prediction circuit, configured to predict the direction of control transfer instructions based on branch history values; A tracking cache circuit, configured to identify and store instruction tracking based on the predicted direction of one or more control transfer instructions; and A next fetch predictor circuit is configured to predict the next fetch address based on the current fetch address, including predicting the next fetch address after performing a first fetch stored in the tracing cache circuit, wherein the first fetch includes multiple fetch groups and multiple control transfer instructions employed.

[0196] C2. The apparatus according to clause C1, the apparatus further comprising: Control circuit, the control circuit being configured to: Pre-calculate branch history update information based on multiple branches used in the first tracking; The branch history update information is stored in the next-follower extraction predictor circuit; and The branch history update information is retrieved in response to a hit in the next extraction predictor circuit.

[0197] C3. The apparatus according to clause C2, wherein the control circuit is further configured to: The retrieved branch history update information is hashed with the current branch history value to generate the updated branch history value.

[0198] C4. The apparatus according to clause C3, wherein the pre-calculation includes: Perform one or more hash operations on the address information associated with a given adopted branch; and Perform one or more left offset operations.

[0199] C5. The apparatus according to clause C3, wherein a smaller number of bits than the current branch history value are used to decode the stored branch history update information.

[0200] C6. An apparatus according to any of the foregoing clauses in set C, wherein at least a portion of the same set of bits of the current fetch address is used to index and label the tracking cache circuit and the tracking next fetch predictor circuit.

[0201] C7. An apparatus according to any of the foregoing clauses in set C, wherein: The prediction circuit is configured to track the direction of the executed control transfer command, which includes: A first category of control transfer instructions, wherein the first category of control transfer instructions conforms to a first threshold bias level toward a given direction; and The second category of control transfer instructions does not conform to the first threshold bias level; The trace cache circuit is configured to identify and store traces of instructions that meet a set of criteria, which include: A given trace includes at least one internal control transfer instruction; The conditional control transfer instruction is only allowed as an internal tracking instruction if it meets a threshold bias level; and Control transfer instructions in the second category are only allowed at the end of a given trace.

[0202] C8. The apparatus according to any of the foregoing provisions in set C, the apparatus further comprising: A non-tracking next-extraction predictor circuit, configured to predict the next extraction address based on the current extraction address; and A control circuit configured to select the prediction performed by the tracking next extract predictor circuit in response to a hit in either the tracking next extract predictor circuit or the non-tracking next extract predictor circuit.

[0203] C9. An apparatus according to any of the foregoing clauses in set C, wherein the next fetch predictor circuit is configured to predict the next fetch address for the loop immediately following the loop in which fetching is performed using the current fetch address.

[0204] C10. A method comprising any combination of operations performed by means of any of the foregoing provisions within set C.

[0205] C11. A non-transitory computer-readable medium storing instructions of a hardware description programming language, which, when processed by a computing system, program the computing system to generate a computer simulation model, wherein the model represents hardware circuitry, the hardware circuitry comprising: Any combination of any of the elements described in the foregoing clauses within set C.

[0206] C12. A non-transitory computer-readable storage medium storing program instructions that are executable to perform any combination of operations performed by any of the means described in the preceding clauses of the set C.

[0207] Set D D1. An apparatus comprising: A processor circuit configured to execute instructions, including control transfer instructions (CTI). An extraction circuit is configured to extract a set of multiple instructions for the processor circuitry in a given clock cycle. A tracking cache circuit, the tracking cache circuit being configured to identify and store instruction traces including a plurality of predicted control transfer instructions; Prediction circuit, the prediction circuit comprising: Table circuitry, the table circuitry being configured to store prediction tables; CTI predictor channel circuitry, configured to access the prediction table to predict the direction of multiple control transfer instructions in a given extraction group; and A tracking predictor channel circuit is configured to access the prediction table to predict the direction of the final control transfer instruction in the tracking cache circuit.

[0208] D2. The apparatus according to clause D1, wherein the tracking predictor channel circuit is configured to access the table circuit using an extract address corresponding to the starting extract group in a given track to predict the address of the control transfer instruction in the last extract group in the given track.

[0209] D3. An apparatus according to any of the foregoing clauses in set D, wherein the table circuitry includes a field for one or more entries indicating whether those entries are used for tracking cache prediction or for non-tracking prediction.

[0210] D4. A device according to any of the foregoing clauses in set D, wherein: The table circuit is configured to store multiple prediction tables, the multiple prediction tables including: Base table; and A multi-level marked geometry length (TAGE) table; and The tracking predictor channel circuit is configured to use a dedicated prediction field from one or more entries in the base table and shares the TAGE table with the CTI predictor channel circuit.

[0211] D5. The apparatus according to clause D4, the apparatus further comprising: The selection circuit is configured to generate tracking cache predictions based on hit results from multiple TAGE tables.

[0212] D6. The apparatus according to clause D4, wherein the prediction circuit is configured to use a fixed location value to make predictions about the tracking cache circuit to avoid overlap with non-tracking predictions.

[0213] D7. The apparatus according to clause D6, wherein the fixed position value corresponds to the start instruction of the cached trace.

[0214] D8. A device according to any of the foregoing clauses in set D, wherein The prediction circuit is configured to track the direction of the executed control transfer command, which includes: A first category of control transfer instructions, wherein the first category of control transfer instructions conforms to a first threshold bias level toward a given direction; and The second category of control transfer instructions does not conform to the first threshold bias level; The trace cache circuit is configured to store traces of instructions that satisfy one or more criteria, the one or more criteria including: The conditional control transfer instruction is only allowed as an internal tracking instruction if it meets a threshold bias level; and Control transfer instructions in the second category are only allowed at the end of a given trace.

[0215] D9. An apparatus according to any of the foregoing clauses in set D, wherein: The prediction circuit is configured such that, for a first control transfer instruction included in tracking as a non-terminating control transfer instruction, both tracking prediction and non-tracking prediction for the first control transfer instruction share table entries and CTI predictor channel circuitry; and The prediction circuit includes a selection circuit configured to: for tracking prediction of the first control transfer command, determine a shared CTI predictor channel circuit based on the position of the first control transfer command in the tracking.

[0216] D10. A method comprising any combination of operations performed by means of any of the foregoing provisions within set D.

[0217] D11. A non-transitory computer-readable medium storing instructions of a hardware description programming language, which, when processed by a computing system, program the computing system to generate a computer simulation model, wherein the model represents hardware circuitry comprising: Any combination of any of the elements described in the preceding clauses within set D.

[0218] D12. A non-transitory computer-readable storage medium storing program instructions that are executable to perform any combination of operations performed by any of the means described in the preceding clauses of the set D.

[0219] The concept of “execution” is broad and can refer to 1) the processing of instructions throughout the entire execution pipeline (e.g., through fetch, decode, execute, and rollback stages), and 2) the processing of instructions at an execution unit or execution subsystem of such a pipeline (e.g., an integer execution unit or a load-memory unit). The latter meaning can also be referred to as a “perform” instruction. Thus, a “perform” addition instruction refers to adding two operands to produce a result, which in some implementations can be achieved by circuitry at the execution stage of the pipeline (e.g., an execution unit). Conversely, “execute” an addition instruction can refer to the entire operation that occurs throughout the pipeline as a result of an addition instruction. Similarly, a “perform” “load” instruction may include (e.g., retrieving a value from a cache, memory, or the stored result of another instruction) and storing the retrieved value in a register or other location.

[0220] As used herein, in the context of instructions, the term "completion" refers to the submission of the result of an instruction to the architectural state of the processor or processing element. For example, the completion of an addition instruction includes writing the result of the addition instruction to the destination register. Similarly, the completion of a load instruction includes writing a value (e.g., a value retrieved from a cache or memory) to the destination register or its representation.

[0221] The concept of a processor "pipeline" is well-known and refers to the division of the "work" a processor does on instructions into multiple stages. In some implementations, instruction decoding, dispatching, execution (i.e., performing), and rollback can be examples of different pipeline stages. Many different pipeline architectures may have different element / part orders. Various pipeline stages perform these steps on instructions during one or more processor clock cycles, then pass the instruction or the operation associated with the instruction to other stages for further processing.

[0222] For a given program or part of a program, the flow is typically sequential. Consider the following instruction set: ldmem1→r1; add r1, r2→r3; st r3→mem2. In this exemplary sequence, the load instruction is executed and completed sequentially, from the add instruction to the store instruction. This order can be considered the default program flow. In this example, none of these instructions affects the selection of the next instruction to be executed and completed (beyond the default behavior).

[0223] In contrast, the execution and completion of instructions with certain opcodes can potentially influence the selection of the next instruction to be executed and completed. These instructions are referred to herein as "control transfer instructions." Control transfer instructions can include, but are not limited to, branching, jumping, calling, and returning. These types of instructions can cause changes to the default behavior of the next instruction to be executed and completed. Control transfer instructions can be used, for example, to execute instruction loops.

[0224] There can also be many different types of control transfer instructions. For example, control transfer instructions can operate conditionally (i.e., set the program counter based on whether a certain condition is true or false) or unconditionally. Similarly, some control transfer instructions can specify a direct target address; others can specify an indirect target address. It should be noted that the execution and completion of control transfer instructions may affect the processor state rather than the location of the next instruction (e.g., there may be instructions that branch after performing arithmetic operations).

[0225] Example Device Now for reference Figure 17A block diagram illustrating an example embodiment of device 1700 is shown. In some embodiments, the components of device 1700 may be included within a system-on-a-chip. In some embodiments, device 1700 may be included in a mobile device that may be battery-powered. Therefore, the power consumption of device 1700 may be an important design consideration. In the illustrated embodiment, device 1700 includes a structure 1710, a computing complex 1720, an input / output (I / O) bridge 1750, a cache / memory controller 1745, a graphics unit 1775, and a display unit 1765. In some embodiments, as supplements or alternatives to the illustrated components, device 1700 may also include other components (not shown), such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.

[0226] Structure 1710 may include various interconnects, buses, MUXs, controllers, etc., and may be configured to facilitate communication between various components of device 1700. In some embodiments, portions of structure 1710 may be configured to implement various different communication protocols. In other embodiments, structure 1710 may implement a single communication protocol, and components coupled to structure 1710 may internally switch from a single communication protocol to other communication protocols.

[0227] In the illustrated embodiments, computing complex 1720 includes a bus interface unit (BIU) 1725, a cache 1730, and cores 1735 and 1740. In various embodiments, computing complex 1720 may include a variety of numbers of processors, processor cores, and caches. For example, computing complex 1720 may include one, two, four, or any other suitable number of processor cores. In one embodiment, cache 1730 is a set-associative L2 cache. In some embodiments, cores 1735 and 1740 may include internal instruction and data caches. In some embodiments, coherence units (not shown) in architecture 1710, cache 1730, or elsewhere in device 1700 may be configured to maintain coherence between the various caches of device 1700. BIU 1725 may be configured to manage communication between computing complex 1720 and other elements of device 1700. Processor cores (such as cores 1735 and 1740) may be configured to execute instructions of a specific instruction set architecture (ISA) that may include operating system instructions and user application instructions.

[0228] In some implementations, the disclosed trace cache technique can improve the performance of one or more cores of the computing complex 1720.

[0229] The cache / memory controller 1745 can be configured to manage data transfer between the structure 1710 and one or more caches and memories. For example, the cache / memory controller 1745 may be coupled to an L3 cache, which in turn may be coupled to system memory. In other embodiments, the cache / memory controller 1745 may be directly coupled to memory. In some embodiments, the cache / memory controller 1745 may include one or more internal caches.

[0230] As used herein, the term "coupled to" can indicate one or more connections between elements, and coupling can include intermediate elements. For example, in Figure 17 In this context, the graphics unit 1775 can be described as being "coupled" to memory via structure 1710 and cache / memory controller 1745. In contrast, in... Figure 17 In the illustrated implementation, the graphics unit 1775 is "directly coupled" to the structure 1710 because there are no intermediate elements.

[0231] The graphics unit 1775 may include one or more processors, such as one or more graphics processing units (GPUs). For example, the graphics unit 1775 may receive graphics-oriented instructions, such as OpenGL. ® Metal or Direct3D ® Instructions. The graphics unit 1775 can execute dedicated GPU instructions or perform other operations based on received graphics-oriented instructions. The graphics unit 1775 is typically configured to process large blocks of data in parallel and can construct an image in a framebuffer for output to a display, which may be included in a device or may be a separate device. The graphics unit 1775 may include a transformation engine, a lighting engine, a triangle engine, and a rendering engine in one or more graphics processing pipelines. The graphics unit 1775 can output pixel information for displaying the image. In various embodiments, the graphics unit 1775 may include programmable shader circuitry, which may include highly parallel execution cores configured to execute graphics programs, which may include pixel tasks, vertex tasks, and computation tasks (which may be graphics-dependent or not).

[0232] Display unit 1765 can be configured to read data from a frame buffer and provide a stream of pixel values ​​for display. In some embodiments, display unit 1765 can be configured as a display pipeline. Additionally, display unit 1765 can be configured to blend multiple frames to produce an output frame. Furthermore, display unit 1765 may include one or more interfaces (e.g., MIPI) for coupling to a user display (e.g., a touchscreen or an external display). ® Or embedded display port (eDP)).

[0233] I / O bridge 1750 may include various components configured to implement functionalities such as Universal Serial Bus (USB) communication, security, audio, and low-power always-on connectivity. I / O bridge 1750 may also include interfaces such as pulse-width modulation (PWM), general-purpose input / output (GPIO), serial peripheral interface (SPI), and internal integrated circuit (I2C). Various types of peripheral devices and equipment can be coupled to device 1700 via I / O bridge 1750.

[0234] In some embodiments, device 1700 includes network interface circuitry (not explicitly shown) that can be connected to structure 1710 or I / O bridge 1750. This network interface circuitry can be configured to communicate via various networks, which can be wired networks, wireless networks, or both. For example, the network interface circuitry can be configured to communicate via a wired local area network (LAN), a wireless LAN (e.g., via WiFi), or a wide area network (e.g., the Internet or a virtual private network). In some embodiments, the network interface circuitry is configured to communicate via one or more cellular networks using one or more radio access technologies. In some embodiments, the network interface circuitry is configured to communicate using device-to-device communication (e.g., Bluetooth or WiFi Direct). In various embodiments, the network interface circuitry can provide device 1700 with connectivity to various types of other devices and networks.

[0235] Example Application Now go to Figure 18 Systems can include any of the circuits, devices, or systems discussed above. Systems or devices 1800 that may utilize one or more of the techniques described herein, in combination with or otherwise, can be used in a wide range of fields. For example, system or device 1800 can be used as part of the hardware of a system such as a desktop computer 1810, a laptop computer 1820, a tablet computer 1830, a cellular or mobile phone 1840, or a television 1850 (or a set-top box coupled to a television).

[0236] Similarly, the disclosed components can be used in wearable devices 1860, such as smartwatches or health monitoring devices. In many embodiments, a smartwatch can perform a variety of different functions—for example, access to email, cellular services, calendars, health monitoring, etc. Wearable devices can also be designed to perform only health monitoring functions, such as monitoring a user's vital signs, performing epidemiological functions such as contact tracing, providing communication to emergency medical services, etc. Other types of devices are also envisioned, including devices worn around the neck, implantable devices, and glasses or helmets designed to provide computer-generated reality experiences, such as those based on augmented reality and / or virtual reality.

[0237] System or device 1800 can also be used in a variety of other contexts. For example, system or device 1800 can be used in the context of a server computer system (such as a dedicated server) or on shared hardware implementing cloud-based services 1870. Furthermore, system or device 1800 can be implemented in a wide range of dedicated everyday devices, including common household devices 1880 such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is often referred to as the “Internet of Things” (IoT). Components can also be implemented in various modes of transportation. For example, system or device 1800 can be used in control systems, guidance systems, entertainment systems, etc., of various types of vehicles 1890.

[0238] Figure 18 The applications illustrated herein are merely exemplary and are not intended to limit the potential future applications of the disclosed systems or devices. Other example applications include, but are not limited to, portable gaming devices, music players, data storage devices, and unmanned aerial vehicles.

[0239] Example Computer-Readable Medium Various example circuits have been described in detail above in this disclosure. It is intended that this disclosure covers not only embodiments including such circuits, but also computer-readable storage media that include design information specifying such circuits. Therefore, this disclosure is intended to support claims that specify storage media for circuits in formats that cover not only means including the disclosed circuits, but also analog models for programming computing systems to generate hardware circuits, computing systems configured to generate hardware (e.g., integrated circuits) including the disclosed circuits. Claims for such storage media are intended to cover entities that, for example, generate circuit designs but do not themselves perform complete operations (such as design simulation, design synthesis, circuit fabrication, etc.).

[0240] Figure 19This is a block diagram illustrating an example non-transitory computer-readable storage medium storing circuit design information according to some embodiments. In the illustrated embodiment, a computing system 1940 is configured to process the design information. This may include executing instructions included in the design information, interpreting instructions included in the design information, compiling, transforming, or otherwise updating the design information. Thus, in some embodiments, the design information (e.g., by programming the computing system 1940) controls the computing system 1940 to perform the various operations discussed below.

[0241] In the illustrated example, computing system 1940 processes the design information to generate both a computer simulation model 1960 of the hardware circuit and lower-level design information 1950. In other embodiments, computing system 1940 may generate only one of these outputs, may generate other outputs based on the design information, or both. Regarding the computational simulation, computing system 1940 may execute instructions in a hardware description language, which includes register-transfer-level (RTL) code, behavioral code, structural code, or some combination thereof. The simulation model may perform the functionality specified by the design information, facilitate verification of the functional correctness of the hardware design, generate power consumption estimates, generate timing estimates, etc.

[0242] In the illustrated example, computing system 1940 further processes the design information to generate lower-level design information 1950 (e.g., gate-level design information, netlists, etc.). As shown, this may include synthesis operations such as constructing multi-level networks, optimizing the network using technology-independent techniques, technology-dependent techniques, or both, and outputting a gate network (with potential constraints based on a library of available gate pairs, size adjustments, delays, power, etc.). Based on the lower-level design information 1950 (and potentially other inputs), semiconductor manufacturing system 1920 is configured to manufacture integrated circuit 1930 (which may correspond to the functionality of analog model 1960). Note that computing system 1940 may generate different analog models based on design information at various descriptive levels (including information 1950, 1915, etc.). Data representing design information 1950 and model 1960 may be stored on medium 1910 or one or more other media.

[0243] In some implementations, lower-level design information 1950 controls (e.g., programs) a semiconductor manufacturing system 1920 to manufacture an integrated circuit 1930. Thus, when processed by the manufacturing system, the design information can program the system to manufacture circuits including the various circuits disclosed herein.

[0244] The non-transitory computer-readable storage medium 1910 may include any of a variety of suitable types of memory devices or storage devices. The non-transitory computer-readable storage medium 1910 may be installation media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory; magnetic media, such as hard disk drives or optical storage devices; registers, or other similar types of memory elements. The non-transitory computer-readable storage medium 1910 may also include other types of non-transitory memory or combinations thereof. Therefore, the non-transitory computer-readable storage medium 1910 may include two or more memory media; such media may reside in different locations—for example, in different computer systems connected via a network.

[0245] Design information 1915 can be specified using any of a variety of suitable computer languages, including hardware description languages ​​such as, but not limited to, VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, etc. The formats of various design information can be recognized by one or more applications executed by computing system 1940, semiconductor manufacturing system 1920, or both. In some embodiments, design information may also include one or more cell libraries specifying the composition, layout, or both of integrated circuit 1930. In some embodiments, design information is specified, wholly or partially, in the form of a netlist specifying cell library elements and their connectivity. Individually, the design information discussed herein may or may not include sufficient information for manufacturing the corresponding integrated circuit. For example, design information may specify circuit elements to be manufactured but not their physical layout. In this case, design information may need to be combined with layout information to actually manufacture the specified circuit.

[0246] In various implementations, the integrated circuit 1930 may include one or more custom macrocells, such as memory and analog or mixed-signal circuitry. In this case, design information may include information associated with the included macrocells. Such information may include, but is not limited to, schematic capture databases, mask design data, behavioral models, and device or transistor-level netlists. Mask design data may be formatted according to a Graphical Data System (GDSII) or any other suitable format.

[0247] The semiconductor manufacturing system 1920 may include any of the various suitable elements configured to manufacture integrated circuits. This may include, for example, elements for depositing semiconductor material (e.g., on a wafer that may include a mask), removing material, changing the shape of the deposited material, modifying the material (e.g., by doping the material or by using ultraviolet treatment to modify the dielectric constant), etc. The semiconductor manufacturing system 1920 may also be configured to perform various tests on the manufactured circuits to ensure proper operation.

[0248] In various embodiments, integrated circuit 1930 and model 1960 are configured to operate according to a circuit design specified by design information 1915, which may include performing any of the functionalities described herein. For example, integrated circuit 1930 may include Figure 1 , Figures 4-8 , Figure 11 and Figure 12 Any of the various components shown herein. Additionally, integrated circuit 1930 can be configured to perform the various functions described herein in conjunction with other components. Furthermore, the functionality described herein can be performed by multiple interconnected integrated circuits.

[0249] As used herein, a phrase in the form of “design information specifying a circuit configured to…” does not imply that the circuit in question must be manufactured to satisfy the element. Rather, the phrase indicates that the design information describes a circuit that, when manufactured, will be configured to perform the indicated actions or will include the specified components. Similarly, stating that “instructions of a hardware description programming language” are “executable” to program a computing system to generate a computer simulation model does not mean that the instructions must be executed to satisfy the element, but rather specifies the characteristics of those instructions. In this case, additional features associated with the model (or the circuit represented by the model) may similarly relate to the characteristics of those instructions. Therefore, an entity selling a computer-readable medium having instructions that satisfy the stated characteristics may provide an infringing product even if another entity actually executes those instructions on the medium.

[0250] It is important to note that a given design, at least within a digital logic context, can be implemented using multiple different gate arrangements, circuit techniques, etc. As an example, different designs may choose or connect gates based on design trade-offs (e.g., focusing on power consumption, performance, circuit area, etc.). Furthermore, different manufacturers may have proprietary libraries, gate designs, physical gate implementations, etc. Different entities may also use different tools to process design information at various layers (e.g., from behavioral specifications to the physical layout of gates).

[0251] However, once a digital logic design is specified, those skilled in the art do not need to perform extensive experiments or studies to determine these implementations. Instead, they understand the process for reliably and predictably producing one or more circuit implementations that provide the functionality described by the design information. Different circuit implementations may affect the performance, area, power consumption, etc., of a given design (potentially trade-offs between different design goals), but the logic function remains unchanged between different circuit implementations of the same circuit design.

[0252] In some implementations, instructions included in the design information instructions provide RTL information (or other higher-level design information) and can be executed by a computing system to synthesize a gate-level netlist representing the hardware circuitry based on the RTL information as input. Similarly, these instructions provide behavioral information and can be executed by the computing system to synthesize netlists or other lower-level design information. This lower-level design information can be used to program the manufacturing system 1920 to manufacture the integrated circuit 1930.

[0253] The various techniques described herein can be executed by one or more computer programs. The term "program" will be broadly interpreted to encompass a sequence of instructions in a programming language executable by a computing device. These programs can be written in any suitable computer language, including lower-level languages ​​such as assembly and higher-level languages ​​such as Python. The program can be written in a compiled language such as C or C++ or an interpreted language such as JavaScript.

[0254] Program instructions may be stored on a “computer-readable storage medium” or “computer-readable medium” to facilitate execution of those instructions by a computer system. Generally, these phrases include any tangible or non-transitory storage medium or memory medium. The terms “tangible” and “non-transitory” are intended to exclude the propagation of electromagnetic signals but do not otherwise limit the type of storage medium. Therefore, the phrase “computer-readable storage medium” or “computer-readable medium” is intended to cover types of storage devices that do not necessarily store information permanently (e.g., random access memory (RAM)). Thus, the term “non-transitory” is a limitation on the nature of the medium itself (i.e., the medium cannot be a signal), which contrasts with limitations on the persistence of data storage in media (e.g., RAM and ROM).

[0255] The phrases “computer-readable storage medium” and “computer-readable medium” are intended to refer to storage media within a computer system as well as removable media such as CD-ROMs, Memory Sticks, or portable hard disk drives. These phrases encompass any type of volatile memory within a computer system, including DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc., as well as non-volatile memory such as magnetic media (e.g., hard disk drives) or optical storage devices. These phrases are explicitly intended to cover the memory of servers that facilitate the download of program instructions, the memory within any intermediate computer systems involved in the download, and the memory of all destination computing devices. Furthermore, these phrases are intended to cover combinations of different types of memory.

[0256] Furthermore, the computer-readable medium or storage medium may reside on one or more computer systems in a first group in which a program is executed, and on one or more computer systems in a second group connected to the first group via a network. In a later example, the second group of computer systems may provide program instructions to the first group of computer systems for execution. In short, the phrases "computer-readable storage medium" and "computer-readable medium" can include two or more media that may reside in different locations (e.g., in different computers connected via a network).

[0257] This disclosure includes references to “implementation” or groups of “implementation” (e.g., “some implementations” or “various implementations”). An implementation is a different specific implementation or instance of the disclosed concepts. References to “implementation,” “an implementation,” and “a particular implementation,” etc., do not necessarily refer to the same implementation. A large number of possible implementations are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the substance or scope of this disclosure.

[0258] This disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all specific implementations of all these embodiments will necessarily exhibit any or all of the potential advantages. Whether a particular embodiment achieves an advantage depends on many factors, some of which are outside the scope of this disclosure. In fact, there are many reasons why an embodiment falling within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular embodiment may include other circuitry outside the scope of this disclosure, in conjunction with one embodiment of the disclosed embodiments, which negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular embodiment (e.g., the implementing technique or tool) may also negate or diminish the disclosed advantages. Even assuming an implementation of the technique, the realization of advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular embodiment may prevent one or more problems addressed in this disclosure from occurring in a particular context, and as a result, the benefits of its solution may not be realized. In view of the existence of possible factors outside this disclosure, it is hereby expressed that any potential advantages described herein should not be construed as a limitation of the claims that must be satisfied in order to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the types of improvements available to the designer who benefits from this disclosure. Describing such advantages permanently (e.g., stating that a particular advantage "may occur") is not intended to convey a question about whether such advantages can actually be realized, but rather to recognize that the realization of such advantages often depends on the technological reality of additional factors.

[0259] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on this disclosure, even where only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative and not restrictive, without any statement to the contrary in this disclosure. Therefore, this application is intended to allow for claims covering the disclosed embodiments, as well as such alternatives, modifications, and equivalents, which will be apparent to those skilled in the art to the advantage of this disclosure.

[0260] For example, features in this application can be combined in any suitable manner. Therefore, new claims may be made for any such combination of features during the filing of this application (or an application claiming priority thereto). Specifically, referring to the appended claims, features of dependent claims may be combined with features of other dependent claims, including claims dependent on other independent claims, where appropriate. Similarly, features from the respective independent claims may be combined where appropriate.

[0261] Thus, although the appended dependent claims may be drafted such that each dependent claim depends from a single other claim, additional dependencies are also contemplated. Any combination of dependent features consistent with the present disclosure is contemplated, and such combinations may be claimed in this application or in another application. In short, the combinations are not limited to those specifically recited in the appended claims.

[0262] In appropriate cases, it is also contemplated that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method).

[0263] Since the present disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. Notice is hereby given that the following paragraphs and the definitions provided throughout the present disclosure will be used to determine how claims drafted based on the present disclosure are to be interpreted.

[0264] References to items in the singular form (i.e., a noun or noun phrase preceded by “a,” “an,” or “the”) are intended to mean “one or more” unless the context clearly dictates otherwise. Thus, without accompanying context, a reference to “an item” in a claim does not exclude additional instances of that item. “A plurality” of items means a collection of two or more of the items.

[0265] The word “may” is used herein in an enabling sense (i.e., having the potential to, being able to), rather than in a mandatory sense (i.e., must).

[0266] The terms “comprising” and “including” and their forms are open-ended and mean “including but not limited to.”

[0267] When the term “or” is used in the present disclosure in relation to a list of options, it will generally be understood to be used in an inclusive sense unless the context otherwise provides. Thus, the statement “x or y” is equivalent to “x or y, or both,” and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as “either x or y, but not both” make clear that “or” is used in an exclusive sense.

[0268] The expressions “w, x, y, or z, or any combination thereof” or “...at least one of w, x, y, and z” are intended to cover all possibilities involving a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element in the set (e.g., w but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. The phrase “...at least one of w, x, y, and z” therefore refers to at least one element in the set [w, x, y, z], thus covering all possible combinations of that list of elements. This phrase should not be interpreted as requiring the existence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0269] In this disclosure, various “labels” may precede nouns or noun phrases. Unless the context otherwise provides, different labels used for features (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels “first,” “second,” and “third” do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0270] The phrase "based on" is used to describe one or more factors that influence the determination. This term does not exclude the possibility that additional factors might influence the determination. That is, the determination may be based solely on the specified factors or on the specified factors along with other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude the possibility that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover implementations where A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0271] The phrases “responding to” and “responding” describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, whether these factors are used in conjunction with or independently of the specified factor. That is, the effect may respond solely to these factors, or it may respond to the specified factor as well as other unspecified factors. Consider the phrase “responding to B and executing A.” This phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. This phrase does not exclude that the execution of A may also respond to certain other factors, such as C. This phrase also does not exclude that the execution of A may be jointly executed in response to B and C. This phrase is also intended to cover implementation schemes where A is executed solely in response to B. As used herein, the phrase “responding” is synonymous with the phrase “at least partially responding to.” Similarly, the phrase “responding to” is synonymous with the phrase “at least partially responding to.”

[0272] Within this disclosure, different entities (which may be referred to differently as “units,” “circuits,” other components, etc.) may be described or protected by the claims as being “configured” to perform one or more tasks or operations. This expression—[entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a tangible thing). More specifically, this expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be considered “configured” to perform a task even if the structure is not currently being operated. Thus, an entity described or stated as being “configured” to perform a task refers to tangible things such as devices, circuits, systems with processor units, and memory storing program instructions executable to perform the task. This phrase is not used herein to refer to intangible things.

[0273] In some cases, various units / circuits / components may be described herein as a collection of entities that perform tasks or operations. It should be understood that these entities are "configured" to perform those tasks / operations, even if not specifically stated otherwise.

[0274] The term "configured as" is not intended to mean "able to be configured as." For example, an unprogrammed FPGA is not considered "configured as" to perform a specific function. However, the unprogrammed FPGA can be "configurable as" to perform that function. After proper programming, the FPGA can then be considered "configured as" to perform a specific function.

[0275] For the purposes of this U.S. patent application based on this disclosure, the statement in the claims that a structure is “configured” to perform one or more tasks is expressly intended not to invoke 35 USC § 112(f) for that claim element. If an applicant wishes to invoke part 112(f) during the filing of a U.S. patent application based on this disclosure, it will use the “component for [performing a function]” structure to state the elements of the claims.

[0276] Different “circuits” may be described in this disclosure. These circuits, or “circuits”, constitute hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom-designed or taken from standard libraries. In various specific implementations, circuits may include digital components, analog components, or a combination of both, depending on the circumstances. Certain types of circuits may be commonly referred to as “cells” (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such cells also refer to circuits or circuitry.

[0277] Therefore, the circuits / units / components and other elements illustrated in the accompanying drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the function of that circuit. For example, a particular “decoding unit” can be described as having the function of executing “the opcode of a processing instruction and routing that instruction to one or more of a plurality of functional units,” meaning that the decoding unit is “configured” to perform that function. To those skilled in the art of computers, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0278] In various implementations, as discussed in the preceding paragraphs, circuits, cells, and other elements can be defined by the functions or operations they are configured to perform. The arrangement of these circuits / cells / components relative to each other and the manner in which they interact form a microarchitecture definition of hardware, which is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Therefore, a microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations can be derived, all of which fall within the broader structure described by the microarchitecture definition. That is, those skilled in the art, with the microarchitecture definition provided according to this disclosure, can implement this structure without excessive experimentation and using the application of a person of ordinary skill in the art, by encoding the description of the circuits / cells / components in a hardware description language (HDL) such as Verilog or VHDL. The HDL description is often expressed in a way that can be revealed as functional. However, for those skilled in the art, the HDL description is a way of translating the structure of a circuit, cell, or component into the details of the next level of implementation. Such HDL descriptions can take the following forms: behavioral code (which is typically non-synthesizable), Register Transfer Language (RTL) code (which is typically synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). HDL descriptions can be sequentially synthesized against a library of cells designed for a given integrated circuit manufacturing technology and can be modified for timing, power, and other reasons to obtain a final design database that is sent to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuitry or portions thereof can also be custom-designed in a schematic editor and captured into the integrated circuit design along with the synthesized circuitry. The integrated circuit can include transistors and other circuit elements (e.g., passive components such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some implementations may implement multiple integrated circuits coupled together to implement the hardware circuitry, and / or discrete components may be used in some implementations. Alternatively, the HDL design can be synthesized into a programmable logic array such as a Field Programmable Gate Array (FPGA) and implemented within the FPGA. This decoupling between the design of a set of circuits and their subsequent low-level implementations often results in a situation where the circuit or logic designer never specifies a particular set of structures for the low-level implementation that goes beyond a description of what the circuit is configured to do, because that process is performed at different stages of the circuit implementation process.

[0279] The fact that a circuit can be implemented to the same specifications using many different low-level combinations of circuit elements results in a large number of equivalent circuit structures. As noted, these low-level circuit implementations can vary depending on the manufacturing technology, the foundry chosen to manufacture the integrated circuit, the cell library provided for a particular project, and so on. In many cases, the choice of different design tools or methods to produce these different implementations can be arbitrary.

[0280] Furthermore, for a given implementation, a single concrete implementation of the circuit's specific functional specifications typically involves a large number of devices (e.g., millions of transistors). Therefore, the shearing volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single implementation, let alone a large number of equivalent possible implementations. To this end, this disclosure describes the structure of a circuit using functional abbreviations commonly used in industry.

Claims

1. An apparatus, the apparatus comprising: A processor circuit configured to execute control transfer instructions; A prediction circuit is configured to track the direction of an executed control transfer instruction, the control transfer instruction including: A first category of control transfer instructions, wherein the first category of control transfer instructions conforms to a first threshold bias level toward a given direction; and The second category of control transfer instructions does not conform to the first threshold bias level; The tracking cache circuit is configured to: The tracking of instructions that identify compliance with a set of criteria includes: A given trace includes at least one internal control transfer instruction; The conditional control transfer instruction is only allowed as an internal tracking instruction if it meets a threshold bias level; and Control transfer instructions in the second category are only allowed at the end of a given tracking period; and Store one or more identified traces.

2. The apparatus of claim 1, wherein the first category comprises only the control transfer instruction in the given direction always being used during execution within a time period.

3. The apparatus of claim 1, wherein the first category includes a control transfer instruction in the given direction at least at a threshold ratio over a time period.

4. The apparatus according to claim 1, further comprising: A filter control circuit, configured to process a third category of control transfer instructions corresponding to a subset of the first category of control transfer instructions that do not meet a second threshold bias level, includes being configured to: For a given internal control transfer instruction of the third category in the stored trace, the counter is adjusted in a first direction in response to the execution of the given control transfer instruction toward the next part of the stored trace, and the counter is adjusted in a second direction in response to the execution of the given control transfer instruction away from the next part of the stored trace. as well as In response to the counter reaching a threshold in the second direction, the given control transfer instruction is prevented from being included in the tracking cache as an internal tracking instruction.

5. The apparatus of claim 1, wherein the prediction circuitry includes a bias predictor configured to generate a prediction for the first category based on a bias table.

6. The apparatus according to claim 1, further comprising: A splicing queue circuit is configured to generate a trace for caching in the tracking cache circuit based on multiple fetch groups retrieved from the instruction cache.

7. The apparatus according to claim 1, further comprising: A training circuit for the tracking cache circuit, wherein the training circuit is configured to: The tracking is buffered until it meets a usefulness threshold. as well as The entries in the tracking cache circuit are verified for tracking that meets one or more criteria and the said usefulness threshold.

8. The apparatus of claim 7, wherein the training circuit is further configured to: Implement a scroll window buffer, in which multiple partially overlapping tracks are buffered; and One of the partially overlapping tracks is selected based on the usefulness value of the partially overlapping tracks for allocation in the tracking cache circuit.

9. The apparatus of claim 8, wherein the training circuit is configured to buffer fetch sets retrieved from the instruction cache and is configured not to buffer fetch sets retrieved from the tracking cache circuit.

10. The apparatus of claim 1, wherein the tracking cache circuitry is configured to identify the tracking of instructions that satisfy a set of standard caches after the decoding phase of the processor circuitry.

11. The apparatus according to claim 1, further comprising: A tracking cache control circuit, wherein the tracking cache control circuit is configured to: The trace will be evicted from the trace cache circuit; as well as The replacement strategy utilizes another trace to replace the trace in the trace cache circuit.

12. The apparatus according to claim 1, further comprising: A single-loop next-fetch predictor circuit is configured to predict the next fetch address after tracking in response to a hit in the tracking cache circuit.

13. The apparatus of claim 1, wherein the prediction circuit comprises: A shared table circuit, configured to store a prediction table; CTI predictor channel circuitry, which is configured to access the prediction table to predict the direction of multiple control transfer instructions in a given extraction group; and A tracking predictor channel circuit is configured to access the prediction table to predict the direction of a tracking end control transfer instruction in the tracking cached by the tracking cache circuit.

14. The apparatus of claim 1, wherein the apparatus is a computing device, the computing device further comprising: Central processing unit; monitor; and Network interface circuit.

15. A method comprising: The processor tracks the direction of executed control transfer instructions, which include: A first category of control transfer instructions, wherein the first category of control transfer instructions conforms to a first threshold bias level toward a given direction; and The second category of control transfer instructions does not conform to the first threshold bias level; The processor identifies the traceability of instructions that satisfy a set of criteria, which include: A given trace includes at least one internal control transfer instruction; The conditional control transfer instruction is only allowed as an internal tracking instruction if it meets a threshold bias level; and Control transfer instructions in the second category are only allowed at the end of a given tracking period; and The processor stores one or more identified traces.

16. The method of claim 15, wherein the first category comprises only the control transfer instruction in the given direction always being used during execution within a time period.

17. The method of claim 15, wherein the operation further comprises: The tracking is buffered until it meets a usefulness threshold. as well as The entries in the tracking cache circuitry are verified for those that meet one or more criteria and the aforementioned usefulness threshold.

18. The method of claim 15, wherein the identifier comprises splicing a trace for caching in the trace cache circuit according to a plurality of fetch groups retrieved from the instruction cache.

19. A non-transitory computer-readable medium storing instructions of a hardware description programming language, which, when processed by a computing system, program the computing system to generate a computer simulation model, wherein the model represents hardware circuitry comprising: A processor circuit configured to execute control transfer instructions; A prediction circuit is configured to track the direction of an executed control transfer instruction, the control transfer instruction including: A first category of control transfer instructions, wherein the first category of control transfer instructions conforms to a first threshold bias level toward a given direction; and The second category of control transfer instructions does not conform to the first threshold bias level; The tracking cache circuit is configured to: The tracking of instructions that identify compliance with a set of criteria includes: A given trace includes at least one internal control transfer instruction; The conditional control transfer instruction is only allowed as an internal tracking instruction if it meets a threshold bias level; and Control transfer instructions in the second category are only allowed at the end of a given tracking period; and Store one or more identified traces.

20. The non-transitory computer-readable medium of claim 19, wherein the first category comprises only control transfer instructions in the given direction that are always employed during execution over a time period.

Images