US 5,764,946 AGrant

Superscalar Microprocessor Employing a Way Prediction Unit to Predict the Way of an Instruction Fetch Address and to Concurrently Provide a Branch Prediction Address Corresponding to the Fetch Address

Issue Date:1998-06-09

•25 Claims

•62 Drawing Sheets

Abstract

A superscalar microprocessor is provided employing a way prediction unit which predicts the next fetch address as well as the way of the instruction cache that the current fetch address hits in while the instructions associated with the current fetch are being read from the instruction cache. The microprocessor may achieve high frequency operation while using an associative instruction cache. An instruction fetch can be made every clock cycle using the predicted fetch address from the way prediction unit until an incorrect next fetch address or an incorrect way is predicted. The instructions from the predicted way are provided to the instruction processing pipelines of the superscalar microprocessor each clock cycle.

Metadata

Assignee

Advanced Micro Devices

Inventors

Thang M. Tran
James K. Pickett

Application Information

Application Number:US 8268843

Filing Date:1997-04-08

Priority Date:1995-04-12

Art Unit:238

Classifications

IPC:

G06F 1200G06F 1300

Field of Search:

364395DIG. 1;DIG. 2;243.4;243.41375;445;452;464;471;800

Patent Drawings (62 sheets)

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of superscalar microprocessors and, more particularly, to branch prediction mechanisms employed within superscalar microprocessors.

2. Description of the Relevant Art

Superscalar microprocessors achieve high performance by simultaneously executing multiple instructions in a clock cycle and by specifying the shortest possible clock cycle consistent with the design. As used herein, the term "clock cycle" refers to an interval of time during which the pipeline stages of a microprocessor preform their intended functions. At the end of a clock cycle, the resulting values are moved to the next pipeline stage.

Since superscalar microprocessors execute multiple instructions per clock cycle and the clock cycle is short, a high bandwidth memory system is required to provide instructions to the superscalar microprocessor (i.e. a memory system that can provide a large number of bytes in a short period of time). Without a high bandwidth memory system, the microprocessor would spend a large number of clock cycles waiting for instructions to be provided, then would execute the received instructions in a relatively small number of clock cycles. Overall performance would be degraded by the large number of idle clock cycles. However, superscalar microprocessors are ordinarily configured into computer systems with a large main memory composed of dynamic random access memory (DRAM) cells. DRAM cells are characterized by access times which are significantly longer than the clock cycle of modern superscalar microprocessors. Also, DRAM cells typically provide a relatively narrow output bus to convey the stored bytes to the superscalar microprocessor. Therefore, DRAM cells provide a memory system that provides a relatively small number of bytes in a relatively long period of time, and do not form a high bandwidth memory system.

Because superscalar microprocessors are typically not configured into a computer system with a memory system having sufficient bandwidth to continuously provide instructions for execution, superscalar microprocessors are is often configured with an instruction cache. Instruction caches are multiple blocks of storage locations, configured on the same silicon substrate as the microprocessor or coupled nearby. The blocks of storage locations are used to hold previously fetched instruction bytes. The bytes can be transferred from the instruction cache to the instruction processing pipelines quickly; commonly one or two clock cycles are required.

Instruction caches are typically organized into an "associative" structure. In an associative structure, the blocks of storage locations are accessed as a two-dimensional array having rows and columns. When a "fetch control unit" (for example, a fetch PC unit) searches the instruction cache for instructions residing at an address, a number of bits from the address are used as an "index" into the cache. The index selects a particular row within the two-dimensional array, and therefore the number of address bits required for the index is determined by the number of rows configured into the instruction cache. The addresses associated with instruction bytes stored in the multiple blocks of a row are examined to determine if any of the addresses stored in the row match the requested address. If a match is found, the access is said to be a "hit", and the instruction cache provides the associated instruction bytes. If a match is not found, the access is said to be a "miss". When a miss is detected, the fetch control unit causes the instruction bytes to be transferred from the memory system into the instruction cache. The addresses associated with instruction bytes stored in the cache are also stored. These stored addresses are referred to as "tags".

The blocks of memory configured into a row form the columns of the row. Each block of memory is referred to as a "way"; multiple ways comprise a row. The way is selected by providing a way value to the instruction cache. The way value is determined by examining the tags for a row and finding a match between one of the tags and the input address from the fetch control unit. As used herein, the term "fetch control unit" refers to a unit configured to fetch instructions from the instruction cache and cause instructions not residing in the instruction cache to be transferred into the instruction cache.

It is well known that associative caches provide better "hit rates" (i.e. a higher percentage of accesses to the cache are hits) than caches that are configured as a linear array of storage locations (typically referred to as a direct-mapped configuration). The hit rates are better for an associative cache because instruction bytes stored at multiple addresses having the same index may be stored in the associative cache simultaneously, whereas a direct-mapped cache is capable of storing one set of instruction bytes per index. For example, a program having a loop that extends over two addresses with the same index can store instruction bytes from both addresses in an associative instruction cache, but will have to repeatedly reload the two addresses each time the loop is executed in a microprocessor having a direct-mapped cache. The hit rate in an instruction cache is important to the performance of the superscalar microprocessor, because when a miss is detected the instructions must be fetched from the memory system. The microprocessor will quickly become idle while waiting for the instructions to be provided. Unfortunately, associative caches require more access time than direct-mapped caches since the tags must be compared to the address being searched for and the resulting hit or miss information must then be used to select which instruction bytes should be conveyed out of the instruction cache to the instruction processing pipelines of the superscalar microprocessor. With the clock cycles of superscalar microprocessors being shortened, this compare and select logic becomes a problem. Often an entire clock cycle or even longer is required to provide instructions from such an instruction cache.

Long instruction cache access times are a particular problem with respect to branch prediction mechanisms. Branch prediction mechanisms predict the next address that a computer program will attempt to fetch from memory, fetch the predicted address, and pass the instructions to the instruction processing pipelines. The predicted address may be the next sequential line in the cache, the target of a branch instruction contained in the current instruction cache line, or some other address. Branch prediction is important to the performance of superscalar microprocessors because they execute multiple instructions per clock cycle. Branches occur often in computer programs, on the average approximately once every four instructions. Therefore, a superscalar microprocessor configured to execute four or more instructions per clock cycle encounters a branch every clock cycle, on the average. Whether or not a particular branch instruction will be taken or not-taken may depend on the result of instructions that are near the branch instruction in the program, and therefore execute in parallel with the branch instruction. Superscalar microprocessors employ branch prediction to allow fetching and speculative execution of instructions while the branch is being executed. Various branch prediction mechanisms are well-known.

Multiple branches are predicted in many superscalar microprocessors so that more instructions may be fetched to prevent the execution units from idling, thereby degrading overall performance. Instructions that are fetched from an address that is mispredicted (i.e. the predicted address is determined to be wrong) may be discarded at later positions in the pipeline. However, for branch prediction to occur, the instructions must be read from the instruction cache to allow scanning of the instructions for branches. Because an associative cache may require the entire clock cycle (or more) to read instructions from the instruction cache, branch prediction would occur in the clock cycle after instructions are read. Branch prediction is a fairly complex function as well, requiring a significant portion of a clock cycle. Therefore, a fetch from a predicted address cannot occur until two cycles after the instruction sequence that contains the branch is fetched from the instruction cache. The instruction cache is accessed once every two cycles, utilizing half of the available instruction cache bandwidth. Better performance would be achieved if the entire available instruction cache bandwidth were used. A solution to the branch prediction and fetch mechanism requiring two cycles in a superscalar microprocessor is therefore desirable.

SUMMARY OF THE INVENTION

The problems outlined above are in large part solved by a superscalar microprocessor employing a way prediction unit in accordance with the present invention. In one embodiment, the way prediction unit predicts the next fetch address as well as the way of the instruction cache that the current fetch address hits while the instructions associated with the current fetch are being read from the instruction cache. Thus the two clock cycle instruction fetch mechanism is advantageously reduced to one clock cycle. Therefore, an instruction fetch can be made every clock cycle until an incorrect next fetch address or an incorrect way is predicted. The instructions from the predicted way are provided to the instruction processing pipelines of the superscalar microprocessor each clock cycle. Relatively higher performance may be achieved than would be possible with a superscalar microprocessor which provides instructions to the instruction processing pipelines every other clock cycle.

The way prediction unit may also enable higher frequencies (shorter clock cycles) while advantageously retaining the performance benefits of an associative instruction cache because the long access time of the associative cache is no longer a limiting factor. The way selection is predicted instead of determined through tag comparisons, removing the dominant barrier to the use of highly associative instruction caches at high frequencies.

Broadly speaking, the present invention contemplates a way prediction unit comprising a first input port, an array and an output port. The first input port conveys an input address and an update value into the way prediction unit. The array includes a plurality of storage locations wherein each of the plurality of storage locations is configured to store an address and a way value. Furthermore, the array includes a mechanism to select one of the plurality of storage locations as indexed by the input address. The output port conveys an output address and an output way value, which are the predicted fetch address for the next clock cycle and the predicted way for the fetch occurring in the current clock cycle.

The present invention further contemplates a mechanism in a microprocessor for predicting the index of a next block of instructions required by a program executing on said microprocessor and for predicting the way of a fetch address accessing the instruction cache in the current clock cycle, comprising a fetch control unit, a way prediction unit, and an instruction cache. The fetch control unit is configured to produce the address and update value that are inputs to the way prediction unit, and is further configured to receive the predicted address and predicted way from the way prediction unit as inputs. The way prediction unit comprises components as described above, and the instruction cache is configured to store blocks of contiguous instruction bytes and to receive a fetch address from the fetch control unit. The present invention still further contemplates a superscalar microprocessor comprising a way prediction unit as described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which:

FIG. 1 is a block diagram of a superscalar microprocessor employing a branch prediction unit in accordance with the present invention.

FIG. 2 is a block diagram of several of the units from FIG. 1, showing a way prediction unit within the branch prediction unit of FIG. 1.

FIG. 3 is a diagram showing the components of the way prediction unit depicted in FIG. 2.

FIG. 4A is a diagram showing the bit fields within a storage location of the way prediction unit depicted in FIG. 3.

FIG. 4B is a timing diagram depicting important relationships between the way prediction unit and the other units depicted in FIG. 2.

FIG. 4C is another timing diagram depicting several instruction fetches and their corresponding way predictions, including a way misprediction cycle.

FIG. 4D is yet another timing diagram depicting several instruction fetches and their corresponding way predictions, including a target fetch address misprediction.

FIG. 5 is a block diagram of a superscalar microprocessor.

FIG. 6 is a block diagram of a pipeline for calculating addresses within processor 500.

FIG. 7 shows a programmer's view of the x86 register file.

FIG. 8 is a block diagram which shows the speculative hardware for the stack relative cache 520.

FIG. 9 is a block diagram which illustrates a portion of an exemplary embodiment of processor 500.

FIG. 10 is a block diagram of the alignment and decode structure of processor 500.

FIG. 11 shows the cycle during which an example sequence of two-byte instructions would be decoded and issued, and to which issue positions each instruction would be dispatched.

FIG. 12 shows the cycle during which an example sequence of one-byte instructions would be decoded and issued, and to which issue positions each instruction would be dispatched.

FIG. 13 shows an example instruction sequence based on exemplary 32-bit application code.

FIG. 14 shows the cycle during which each instruction would be decoded and issued, and to which issue positions each instruction would be dispatched.

FIG. 15 illustrates the execution cycle of the processor 500 pipeline with a branch misprediction detected.

FIG. 16 illustrates the execution cycle of the processor 500 pipeline with a successful branch prediction.

FIG. 17 is a block diagram of instruction cache 502.

FIG. 18 illustrates aspects of instruction cache 502.

FIG. 19 is diagram of the ICTAGV layout.

FIG. 20 illustrates aspects of the ICNXTBLK.

FIG. 21 is a block diagram of a global branch predictor.

FIG. 22 is a block diagram of the ICNXTBLK block.

FIG. 23 is a block diagram of the ICPREFIX block.

FIG. 24 is a block diagrams of the ICALIGN block.

FIG. 25 illustrates aspects of the ICALIGN block.

FIG. 26 shows an embodiment of the ICCNTL state machine.

FIG. 27 is a block diagram of the Icache and fetching mechanism.

FIG. 28 shows the conditions necessary to validate the instruction and each byte.

FIG. 29 is a block diagram of hardware within processor 500 which is used to calculate linear addresses and identify register operands.

FIG. 30 is a block diagram showing how operands identified and provided to the reservation stations and functional units.

FIG. 31 is a block diagram of the return stack mechanism.

FIG. 32 is a block diagram of the MROM Interface Unit (MIU).

FIG. 33 is a block diagram showing how processor 500 extends the register set for MROM instructions.

FIG. 34 is a block diagram of how two-cycle fast path instructions are handled.

FIG. 35 is a block diagram of the layout of the processor 500 instruction decode unit.

FIG. 36 is a block diagram showing how the LOROB interfaces with other processor 500 units.

FIG. 37 shows the layout of the result data of the LOROB, the stack cache, and the register file.

FIG. 38 is a block diagram of the matrix for dependency checking in the LOROB.

FIG. 39 is a block diagram showing the dependency checking required for store operations.

FIG. 40 is a block diagram showing is dependency checking required for load operations.

FIG. 41 is a block diagram of a layout of the LOROB.

FIG. 42 is a block diagram of the stack cache.

FIG. 43 is a block digram of the look-ahead ESP and EBP register models.

FIG. 44 is a block digram of the current within line dependency checking unit.

FIG. 45 is a block diagram illustrating how the last in line bits are set.

FIG. 46 is a block diagram illustrating the previous line dependency checking operation performed in the LOROB.

FIG. 47 is a block diagram showing portions of the processor 500 which interface with the register file and special register block.

FIG. 48 is a block diagram of a reservation station.

FIG. 49 is a block diagram of the bus structure for the reservation stations.

FIG. 50 is a reservation station timing diagram.

FIG. 51 is a block diagram of a functional unit.

FIG. 52 is a code sequence showing how the same instructions could receive tags/operands from different sources.

FIG. 53 is a block diagram of the load/store section.

FIG. 54 is a block diagram of the unified load-store buffer.

FIG. 55 is a block diagram of a load-store buffer entry.

FIG. 56 is a timing digram showing when the different fields in each entry of the buffer are updated.

FIG. 57 is a block diagram which illustrates store data forwarding for loads.

FIG. 58 shows a layout configuration of the LSSEC.

FIG. 59 shows the relative position of the LSSEC with respect to other units.

FIG. 60 is a block diagram of the data cache.

FIG. 61 is a block diagram of a tag array entry.

FIG. 62 is a block diagram of a way prediction entry.

FIG. 63 is a timing diagram for dcache load accesses.

FIG. 64 is a block diagram showing way prediction array entry usage for loads.

FIG. 65 is a timing diagram for dcache store accesses.

FIG. 66 is a timing diagram for unaligned load accesses.

FIG. 67 is a timing diagram for unaligned store accesses.

FIG. 68 is a timing diagram for DC/SC line transfers.

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

DETAILED DESCRIPTION OF THE INVENTION

Turning now to the drawings, FIG. 1 shows a block diagram of a superscalar microprocessor 200 including a branch prediction unit 220 employing a way prediction unit in accordance with the present invention. As illustrated in the embodiment of FIG. 1, superscalar microprocessor 200 includes a prefetch/predecode unit 202 and a branch prediction unit 220 coupled to an instruction cache 204. Instruction alignment unit 206 is coupled between instruction cache 204 and a plurality of decode units 208A-208F (referred to collectively as decode units 208). Each decode unit 208A-208F is coupled to a respective reservation station unit 210A-210F (referred collectively as reservation stations 210), and each reservation station 210A-210F is coupled to a respective functional unit 212A-212F (referred to collectively as functional units 212). Decode units 208, reservation stations 210, and functional units 212 are further coupled to a reorder buffer 216, a register file 218 and a load/store unit 222. A data cache 224 is finally shown coupled to load/store unit 222, and an MROM unit 209 is shown coupled to instruction alignment unit 206.

Generally speaking, instruction cache 204 is a high speed cache memory provided to temporarily store instructions prior to their dispatch to decode units 208. In one embodiment, instruction cache 204 is configured to cache up to 32 kilobytes of instruction code organized in lines of 16 bytes each (where each byte consists of 8 bits). During operation, instruction code is provided to instruction cache 204 by prefetching code from a main memory (not shown) through prefetch/predecode unit 202.

Prefetch/predecode unit 202 is provided to prefetch instruction code from the main memory for storage within instruction cache 204. In one embodiment, prefetch/predecode unit 202 is configured to burst 64-bit wide code from the main memory into instruction cache 204. It is understood that a variety of specific code prefetching techniques and algorithms may be employed by prefetch/predecode unit 202.

As prefetch/predecode unit 202 fetches instructions from the main memory, it generates three predecode bits associated with each byte of instruction code: a start bit, an end bit, and a "functional" bit. The predecode bits form tags indicative of the boundaries of each instruction. The predecode tags may also convey additional information such as whether a given instruction can be decoded directly by decode units 208 or whether the instruction must be executed by invoking a microcode procedure controlled by MROM unit 209, as will be described in greater detail below.

Table 1 indicates one encoding of the predecode tags. As indicated within the table, if a given byte is the first byte of an instruction, the start bit for that byte is set. If the byte is the last byte of an instruction, the end bit for that byte is set. If a particular instruction cannot be directly decoded by the decode units 208, the functional bit associated with the first byte of the instruction is set. On the other hand, if the instruction can be directly decoded by the decode units 208, the functional bit associated with the first byte of the instruction is cleared. The functional bit for the second byte of a particular instruction is cleared if the opcode is the first byte, and is set if the opcode is the second byte. It is noted that in situations where the opcode is the second byte, the first byte is a prefix byte. The functional bit values for instruction byte numbers 3-8 indicate whether the byte is a MODRM or an SIB byte, as well as whether the byte contains displacement or immediate data.

As stated previously, in one embodiment certain instructions within the x86 instruction set may be directly decoded by decode units 208. These instructions are referred to as "fast path" instructions. The remaining instructions of the x86 instruction set are referred to as "MROM instructions". MROM instructions are executed by invoking MROM unit 209. When an MROM instruction is encountered, MROM unit 209 parses and serializes the instruction into a subset of defined fast path instructions to effectuate a desired operation. A listing of exemplary x86 instructions categorized as fast path instructions as well as a description of the manner of handling both fast path and MROM instructions will be provided further below.

Instruction alignment unit 206 is provided to channel variable byte length instructions from instruction cache 204 to fixed issue positions formed by decode units 208A-208F. Instruction alignment unit 206 is configured to channel instruction code to designated decode units 208A-208F depending upon the locations of the start bytes of instructions within a line as delineated by instruction cache 204. In one embodiment, the particular decode unit 208A-208F to which a given instruction may be dispatched is dependent upon both the location of the start byte of that instruction as well as the location of the previous instruction's start byte, if any. Instructions starting at certain byte locations may further be restricted for issue to only one predetermined issue position. Specific details follow.

Before proceeding with a detailed description of the way prediction unit within branch prediction unit 220, general aspects regarding other subsystems employed within the exemplary superscalar microprocessor 200 of FIG. 1 will be described. For the embodiment of FIG. 1, each of the decode units 208 includes decoding circuitry for decoding the predetermined fast path instructions referred to above. In addition, each decode unit 208A-208F routes displacement and immediate data to a corresponding reservation station unit 210A-210F. Output signals from the decode units 208 include bit-encoded execution instructions for the functional units 212 as well as operand address information, immediate data and/or displacement data.

The superscalar microprocessor of FIG. 1 supports out of order execution, and thus employs reorder buffer 216 to keep track of the original program sequence for register read and write operations, to implement register renaming, to allow for speculative instruction execution and branch misprediction recovery, and to facilitate precise exceptions. As will be appreciated by those of skill in the art, a temporary storage location within reorder buffer 216 is reserved upon decode of an instruction that involves the update of a register to thereby store speculative register states. Reorder buffer 216 may be implemented in a first-in-first-out configuration wherein speculative results move to the "bottom" of the buffer as they are validated and written to the register file, thus making room for new entries at the "top" of the buffer. Other specific configurations of reorder buffer 216 are also possible, as will be described further below. If a branch prediction is incorrect, the results of speculatively-executed instructions along the mispredicted path can be invalidated in the buffer before they are written to register file 218.

The bit-encoded execution of instructions and immediate data provided at the outputs of decode units 208A-208F are routed directly to respective reservation station units 210A-210F. In one embodiment, each reservation station unit 210A-210F is capable of holding instruction information (i.e., bit encoded execution bits as well as operand values, operand tags and/or immediate data) for up to three pending instructions awaiting issue to the corresponding functional unit. It is noted that for the embodiment of FIG. 1, each decode unit 208A-208F is associated with a dedicated reservation station unit 210A-210F, and that each reservation station unit 210A-210F is similarly associated with a dedicated functional unit 212A-212F. Accordingly, six dedicated "issue positions" are formed by decode units 208, reservation station units 210 and functional units 212. Instructions aligned and dispatched to issue position 0 through decode unit 208A are passed to reservation station unit 210A and subsequently to functional unit 212A for execution. Similarly, instructions aligned and dispatched to decode unit 208B are passed to reservation station unit 210B and into functional unit 212B, and so on.

Upon decode of a particular instruction, if a required operand is a register location, register address information is routed to reorder buffer 216 and register file 218 simultaneously. Those of skill in the art will appreciate that the x86 register file includes eight 32 bit real registers (i.e., typically referred to as EAX, EBX, ECX, EDX, EBP, ESI, EDI and ESP), as will be described further below. Reorder buffer 216 contains temporary storage locations for results which change the contents of these registers to thereby allow out of order execution. A temporary storage location of reorder buffer 216 is reserved for each instruction which, upon decode, modifies the contents of one of the real registers. Therefore, at various points during execution of a particular program, reorder buffer 216 may have one or more locations which contain the speculatively executed contents of a given register. If following decode of a given instruction it is determined that reorder buffer 216 has previous location(s) assigned to a register used as an operand in the given instruction, the reorder buffer 216 forwards to the corresponding reservation station either: 1) the value in the most recently assigned location, or 2) a tag for the most recently assigned location if the value has not yet been produced by the functional unit that will eventually execute the previous instruction. If the reorder buffer has a location reserved for a given register, the operand value (or tag) is provided from reorder buffer 216 rather than from register file 218. If there is no location reserved for a required register in reorder buffer 216, the value is taken directly from register file 218. If the operand corresponds to a memory location, the operand value is provided to the reservation station unit through load/store unit 222.

Details regarding suitable reorder buffer implementations may be found within the publication "Superscalar Microprocessor Design" by Mike Johnson, Prentice-Hall, Englewood Cliffs, N.J., 1991, and within the co-pending, commonly assigned patent application entitled "High Performance Superscalar Microprocessor", Ser. No. 08/146,382, filed Oct. 29, 1993 by Witt, et al. These documents are incorporated herein by reference in their entirety.

Reservation station units 210A-210F are provided to temporarily store instruction information to be speculatively executed by the corresponding functional units 212A-212F. As stated previously, each reservation station unit 210A-210F may store instruction information for up to three pending instructions. Each of the six reservation stations 210A-210F contain locations to store bit-encoded execution instructions to be speculatively executed by the corresponding functional unit and the values of operands. If a particular operand is not available, a tag for that operand is provided from reorder buffer 216 and is stored within the corresponding reservation station until the result has been generated (i.e., by completion of the execution of a previous instruction). It is noted that when an instruction is executed by one of the functional units 212A-212F, the result of that instruction is passed directly to any reservation station units 210A-210F that are waiting for that result at the same time the result is passed to update reorder buffer 216 (this technique is commonly referred to as "result forwarding"). Instructions are issued to functional units for execution after the values of any required operand(s) are made available. That is, if an operand associated with a pending instruction within one of the reservation station units 210A-210F has been tagged with a location of a previous result value within reorder buffer 216 which corresponds to an instruction which modifies the required operand, the instruction is not issued to the corresponding functional unit 212 until the operand result for the previous instruction has been obtained. Accordingly, the order in which instructions are executed may not be the same as the order of the original program instruction sequence. Reorder buffer 216 ensures that data coherency is maintained in situations where read-after-write dependencies occur.

In one embodiment, each of the functional units 212 is configured to perform integer arithmetic operations of addition and subtraction, as well as shifts, rotates, logical operations, and branch operations. It is noted that a floating point unit (not shown) may also be employed to accommodate floating point operations.

Each of the functional units 212 also provides information regarding the execution of conditional branch instructions to the branch prediction unit 220. If a branch prediction was incorrect, branch prediction unit 220 flushes instructions subsequent to the mispredicted branch that have entered the instruction processing pipeline, and causes prefetch/predecode unit 202 to fetch the required instructions from instruction cache 204 or main memory. It is noted that in such situations, results of instructions in the original program sequence which occur after the mispredicted branch instruction are discarded, including those which were speculatively executed and temporarily stored in load/store unit 222 and reorder buffer 216. Exemplary configurations of suitable branch prediction mechanisms are well known.

Results produced by functional units 212 are sent to the reorder buffer 216 if a register value is being updated, and to the load/store unit 222 if the contents of a memory location is changed. If the result is to be stored in a register, the reorder buffer 216 stores the result in the location reserved for the value of the register when the instruction was decoded. As stated previously, results are also broadcast to reservation station units 210A-210F where pending instructions may be waiting for the results of previous instruction executions to obtain the required operand values.

Data cache 224 is a high speed cache memory provided to temporarily store data being transferred between load/store unit 222 and the main memory subsystem. In one embodiment, data cache 224 has a capacity of storing up to eight kilobytes of data. It is understood that data cache 224 may be implemented in a variety of specific memory configurations, including a set associative configuration.

Generally speaking, load/store unit 222 provides an interface between functional units 212A-212F and data cache 224. In one embodiment, load/store unit 222 is configured with a load/store buffer with sixteen storage locations for data and address information for pending load or store memory operations. Functional units 212 arbitrate for access to the load/store unit 222. The load/store unit 222 also performs dependency checking for load memory operations against pending store memory operations to ensure that data coherency is maintained.

Turning now to FIG. 2, a block diagram of a portion of microprocessor 200 is shown. Included in the diagram is instruction cache 204 and branch prediction unit 220. Instruction cache 204 is further coupled to instruction alignment unit 206 and decode units 208 (shown in this diagram as a single block, although decode units 208 are shown as several blocks in FIG. 1). Within branch prediction unit 220 is a way prediction unit 250 in accordance with the present invention. Branch prediction unit 220 may also contain other units (not shown). In one embodiment, instruction cache 204 is eight-way associative. Shown within instruction cache 204 is a fetch PC unit 254 and instruction cache storage 255.

Generally speaking, way prediction unit 250 generates a predicted fetch address for the next cache line to be fetched (i.e. a prediction of the branch prediction address) and a predicted way value for the fetch address accessing the instruction cache in the current clock cycle (the "current fetch address"). The predicted fetch address and predicted way are based on the current fetch address. By predicting the branch prediction address, microprocessor 200 is able to read the predicted line from instruction cache 204 while the branch prediction is being generated, advantageously removing a clock cycle from the instruction fetch process in cases where the predicted fetch address matches the branch prediction address. Furthermore, predicting the way for the current fetch address makes the instructions for the current fetch address available by the end of the clock cycle in which the fetch address accesses the cache, as opposed to the next cycle if the tag comparison information is used to select the instructions. The predicted way is validated by the tag comparison information in the following cycle.

The predicted fetch address and predicted way are transferred on a prediction bus 251 to fetch PC unit 254. In one embodiment, the predicted fetch address is a partial address containing the index bits used to index instruction cache 204. Way prediction unit 250 predicts the next instruction cache line index to be fetched and the way of the instruction cache which contains the current fetch address using the current fetch address, as conveyed from fetch PC unit 254 on a fetch request bus 252. Fetch request bus 252 also conveys way selection information for instruction cache 204, and a next index address which is the current fetch address incremented by the size of one instruction cache line. In one embodiment, the instruction cache line size is sixteen bytes and therefore the next index address is the current fetch address incremented by sixteen.

The current fetch address conveyed on fetch request bus 252 is the predicted fetch address conveyed by way prediction unit 250 in the previous clock cycle, except for cycles in which fetch PC unit 254 detects a way or predicted fetch address misprediction. During the clock cycle following a fetch address access to the cache, the way prediction and the predicted fetch address generated for that fetch address are validated. The way prediction is validated by comparing the actual way that the fetch address hits in instruction cache 204 (determined via a tag compare to the full fetch address) to the way prediction. If the way prediction matches the actual way, then the way prediction is correct. If the way prediction is wrong, then the correct way is selected from the eight ways of instruction cache 204 (which were latched from the previous clock cycle), the instructions associated with the predicted way are discarded, and the predicted fetch address is discarded as well. If the way prediction is correct, then the predicted fetch address is validated by comparing the predicted fetch address to the branch prediction address generated by branch prediction unit 220. In embodiments where the predicted fetch address is an index address, only the index bits of the branch prediction address are compared to the predicted fetch address. If the index bits match, the two addresses are defined to match and the branch prediction address is then used in the tag compares for the instruction cache lines associated with the predicted fetch address. If the predicted fetch address is incorrect, the associated instructions are discarded and the branch prediction address is fetched.

As mentioned above, fetch PC unit 254 sends update information to way prediction unit 250 on fetch request bus 252. The update information for a particular predicted fetch address is sent the clock cycle following the predicted address validation, and includes an update way value and update selection control bits. If the prediction is correct, the update information is the predicted information. If the prediction is incorrect, the update way value is the way of instruction cache 204 which contains the instructions actually fetched and the update selection control bits indicate whether the branch prediction address is a taken branch, a next sequential line fetch, or a RET instruction. The update information is stored by way prediction unit 250 such that the next prediction using a similar current fetch address will include the update information in the prediction mechanism. The prediction mechanism will be explained in more detail with respect to FIG. 3.

FIG. 2 also depicts a return stack address bus 253 connected to way prediction unit 250. Return stack address bus 253 conveys the address that is currently at the top of the return stack in decode units 208. The return stack is a stack of addresses that refer to instructions following previously executed CALL instructions. A RET instruction would use the address at the top of the return stack to locate the next instruction to be executed. As will be appreciated by one skilled in the art, the CALL and RET instructions are defined by the x86 architecture as subroutine entrance and exit instructions, respectively.

Way prediction unit 250 uses the next index address provided on fetch request bus 252 and the return stack address as sources for the predicted fetch address. The return stack address is selected during clock cycles in which way prediction unit 250 predicts that a RET instruction is in the cache line currently being fetched. Alternatively, the next index address is selected during clock cycles in which way prediction unit 250 predicts that no branch-type instructions exist in the cache line currently being fetched. Way prediction unit 250 also selects internally stored addresses as the predicted fetch address during clock cycles in which the prediction mechanism predicts that a branch-type instruction exists in the cache line, as will be described in further detail below.

Turning now to FIG. 3, an embodiment of way prediction unit 250 is shown with return stack bus 253 and fetch request bus 252 connected to it. The current fetch address conveyed on fetch request bus 252 is decoded by decoder circuit 300. The resulting select lines are stored by a delay latch 301, and also select a storage location from a way prediction array 302. In this embodiment, way prediction array 302 is configured as a linear array of storage locations. In another embodiment prediction array 302 is composed of registers. Each storage location is configured to store prediction addresses, a predicted way, and target selection control bits. The prediction addresses are branch prediction addresses previously generated from instructions residing at a fetch address with the same index bits as the current fetch address. The predicted way is the last correctly predicted way for a fetch address with the same index as the current fetch address. The target selection control bits indicate which of the stored prediction addresses should be selected, or if the next index address or the return stack address should be selected. When microprocessor 200 is initialized, the target selection control bits of storage locations with way prediction array 302 are set to select the next index address.

Delay latch 301 transfers its value to an update latch 304. Update latch 304 selects a storage location within way prediction array 302 for storing the update information provided by fetch PC unit 254. Delay latch 301 and update latch 304 store the decoded selection lines for way prediction array 302, and thus avoid the need for a second decoder circuit similar to decoder 300. As will be appreciated by one skilled in the art, a decoder circuit such as decoder 300 is larger (in terms of silicon area) than delay latch 301 and update latch 304. Therefore, silicon area is saved by implementing this embodiment instead of an embodiment with a second decoder for updates.

Way prediction unit 250 is also configured with an address selection device for selecting the address to provide as the predicted fetch address. In this embodiment, the address selection device is a multiplexor 305 and an address selection circuit 306. Address selection circuit 306 receives the target selection control bits from way prediction array 302 and produces multiplexor select lines for multiplexor 305. In one embodiment, address selection circuit 306 causes multiplexor 305 to select: the first address from way prediction array 302 if the target selection control bits contain the binary value "01", the second address from way prediction array 302 if the target selection control bits contain the binary value "10", the next index address from fetch request bus 252 if the target selection bits contain the binary value "00", and the return stack address from return stack address bus 253 if the selection control bits contain the binary value "11". Therefore, address selection circuit 306 is a decode of the target selection control bits. The predicted address is conveyed on prediction bus 251 along with the predicted way selected from way prediction array 302.

Turning now to FIG. 4A, a diagram of one of the storage locations of way prediction array 302 (shown in FIG. 3) is shown. In this embodiment, two prediction addresses are stored (shown as fields 400 and 401). Each of the prediction addresses are 12 bits wide. Way prediction information is stored in a field 402 which is 3 bits wide in this embodiment to encode the eight ways of instruction cache 204. In another embodiment, field 402 is 8 bits wide and the way prediction information is not encoded. Instead, one of the eight bits is set indicating the predicted way. Target selection bits are also stored within the storage location in field 403 which is 2 bits wide in this embodiment to encode selection of prediction address field 400, prediction address field 401, the next index address, or the return stack address. In another embodiment, field 403 is four bits wide and the target selection bits are not encoded. Instead, one of the 4 bits is set indicating one of the four possible prediction addresses.

Turning now to FIG. 4B, a timing diagram depicting important relationships between way prediction unit 250, instruction cache 204 and fetch PC unit 254 is shown. At the beginning of ICLK1, a current fetch address is sent from fetch PC unit 254 to instruction cache 204 and way prediction unit 250. Instruction cache 204 transfers the associated instructions to its output bus during the time indicated by the horizontal line 420 and latches them. In parallel, way prediction unit 250 indexes into way prediction array 302 and selects a storage location. From the value of the target selection control bits stored within the selected storage location, a predicted fetch address is generated. The predicted fetch address and the predicted way from the selected storage location are conveyed to fetch PC unit 254 near the end of ICLK1, as indicated by arrow 421. The predicted way is selected from the eight ways indexed by the current fetch address in ICLK1, and the selected instructions are scanned to form a branch prediction address. Also, the selected instructions are forwarded to instruction alignment unit 206 in ICLK2.

In ICLK2, the predicted fetch address is conveyed as the current fetch address. In parallel, fetch PC unit 254 determines whether or not the previous fetch address is an instruction cache hit in the predicted way and branch prediction unit 220 generates a branch prediction address, as indicated by arrow 422. This information is used as described above to validate the predicted fetch address that is currently accessing instruction cache 204 and the predicted way that was provided in ICLK1. If a way misprediction is detected, the correct instructions are selected from the eight ways of instruction cache 204 latched in ICLK1, and the instructions read in ICLK1 are discarded. If a predicted address misprediction is detected, then the branch prediction address is fetched in ICLK3 at arrow 423 and the instructions read in ICLK2 are ignored. Otherwise, the predicted fetch address received during ICLK2 from way prediction unit 250 is used. Also at arrow 423, the way prediction and control selection bits are updated in way prediction unit 250 for the address fetched in ICLK1. ICLK4 is the clock cycle in which the RET instruction is detected and the return stack address prediction is validated, as shown at arrow 424. If the return stack address prediction is incorrect, then the corrected address is fetched and the way prediction information is updated at arrow 425. In one embodiment, return stack address predictions require two extra clock cycles to validate (as indicated by FIG. 4B) as compared to next index address or branch prediction address predictions.

Turning now to FIG. 4C, a timing diagram is shown to illustrate way misprediction. In ICLK1, a current fetch address A is conveyed to instruction cache 204 and way prediction unit 250, as indicated by block 440. A prediction address B is determined by way prediction unit 250 and conveyed to fetch PC unit 254 as indicated by block 441. In ICLK2 address B is conveyed as a current fetch address because it was predicted in ICLK1, as indicated by block 442. In response to current fetch address B, prediction address C is determined by way prediction unit 250 and conveyed to fetch PC unit 254 as indicated by block 443. At arrow 444, address A is determined to hit in the instruction cache in the predicted way, and at arrow 445 a branch prediction associated with address A is calculated. The branch prediction address matches the predicted address B, and therefore address B is a valid prediction.

In ICLK3 at arrow 446, the predicted way for address B is found to be incorrect. Therefore, the correct instructions are selected from the eight ways that were latched in the previous cycle, as indicated by block 447. The instructions read in ICLK2 are discarded. Also, a new predicted address C' is conveyed as indicated by block 448. In ICLK4, address C' is fetched as indicated by box 449.

Turning now to FIG. 4D, a timing diagram is shown depicting several consecutive instruction fetches, to further illustrate the interaction between fetch PC unit 254, way prediction unit 250, and instruction cache 204. In ICLK1, a current fetch address A is conveyed to instruction cache 204 and way prediction unit 250, as indicated by block 460. A prediction address B is determined by way prediction unit 250 and conveyed to fetch PC unit 254 as indicated by block 461. In ICLK2 address B is conveyed as a current fetch address because it was predicted in ICLK1, as indicated by block 462. In response to current fetch address B, prediction address C is determined by way prediction unit 250 and conveyed to fetch PC unit 254 as indicated by block 463. At arrow 464, address A is determined to hit in the instruction cache in the predicted way, and at arrow 465 a branch prediction associated with address A is calculated. The branch prediction address matches the predicted address B, and therefore address B is a valid prediction.

In ICLK3, address C is used as the current fetch address, as indicated by block 466. As for address A in ICLK2, address B is determined to be a hit in the predicted way as indicated by arrow 467. However, at arrow 468 the branch prediction associated with address B is determined and the branch prediction address does not match address C. Therefore, the predicted fetch address being conveyed in ICLK3 is ignored as well as the instructions associated with address C. In ICLK4, the corrected branch prediction address C' is used as the current fetch address as indicated by block 469. A predicted fetch address and way based on corrected address C' is made by way prediction unit 250 in ICLK4, and the current fetch address for ICLK5 will reflect that prediction.

It is noted that the number and size of addresses stored within way prediction array 302 may differ for other embodiments. In particular, the number of addresses stored may be more or less than the embodiment of FIG. 3. Furthermore, the number of external addresses added to the address prediction selection may vary from embodiment to embodiment, as will the number and encoding of the target selection control bits. It is also noted that the portion of the address stored within way prediction array 302 may vary from embodiment to embodiment, and the entire address may be stored in another embodiment. It is further noted that other embodiments could store multiple way predictions and select among them in a manner similar to the address selection device shown in FIG. 3. It is also noted that some embodiments may store other information with each predicted address in way prediction array 302. For example, a way, a byte position with the instruction cache line, and branch prediction counter information may be stored within fields 400 and 401.

Turning next to FIGS. 5-68, details regarding various aspects of another embodiment of a superscalar microprocessor are next considered. FIG. 5 is a block diagram of a processor 500 including an instruction cache 502 coupled to a prefetch/predecode unit 504, to a branch prediction unit 506, and to an instruction alignment unit 508. A set 510 of decode units is further coupled to instruction alignment unit 508, and a set 512 of reservation station/functional units is coupled to a load/store unit 514 and to a reorder buffer 516. A register file unit 518 and a stack cache 520 is finally shown coupled to reorder buffer 516, and a data cache 522 is shown coupled to load/store unit 514.

Processor 500 limits the addressing mechanism used in the x86 to achieve both regular simple form of addressing as well as high clock frequency execution. It also targets 32-bit O/S and applications. Specifically, 32-bit flat addressing is employed where all the segment registers are mapped to all 4GB of physical memory. The starting address being 0000-0000 hex and their limit address being FFFF hex. The setting of this condition will be detected within processor 500 as one of the conditions to allow the collection of accelerated datapaths and instructions to be enabled. The absence of this condition of 32-bit flat addressing will cause a serialization condition on instruction issue and a trapping to MROM space.

Another method to insure that a relatively high clock frequency may be accommodated is to limit the number of memory address calculation schemes to those that are simple to decode and can be decoded within a few bytes. We are also interested in supporting addressing that fits into our other goals, i.e., stack relative addressing and regular instruction decoding.

As a result, the x86 instruction types that are supported for load/store operations are:

The block diagram of FIG. 6 shows the pipeline for calculating addressing within processor 500. It is noted that base +8/32 bit displacement takes 1 cycle, where using an index register takes 1 more cycle of delay in calculating the address. More complicated addressing than these requires invoking an MROM routine to execute.

A complete listing of the instruction sub-set supported by processor 500 as fast path instructions is provided below. All other x86 instructions will be executed as micro-ROM sequences of fast path instructions or extensions to fast path instructions.

The standard x86 instruction set is very limited in the number of registers it provides. Most RISC processors have 32 or greater general purpose registers, and many important variables can be held during and across procedures or processes during normal execution of routines. Because there are so few registers in the x86 architecture and most are not general purpose, a large percentage of operations are moves to and from memory. RISC architectures also incorporate 3 operand addressing to prevent moves from occurring of register values that are desired to be saved instead of overwritten.

The x86 instruction set uses a set of registers that can trace its history back to the 8080. Consequently there are few resisters, many side effects, and sub-registers within registers. This is because when moving to 16-bit, or 32-bit operands, mode bits were added and the lengths of the registers were extended instead of expanding the size of the register file. Modern compiler technology can make use of large register sets and have a much smaller percentage of loads and stores. The effect of these same compilers is to have a much larger percentage of loads and stores when compiling to the x86. The actual x86 registers are often relegated to temporary registers for a few clock cycles while the real operation destinations are in memory.

FIG. 7 shows a programmer's view of the x86 register file. One notes from this organization that there are only 8 registers, and few are general purpose. The first four registers, EAX, EDX, ECX, and EBX, have operand sizes of 8, 16, or 32-bits depending on the mode of the processor or instruction. The final 4 resisters were added with the 8086 and extended with the 386. Because there are so few real registers, they tend to act as holding positions for the passing of variables to and from memory.

The important thing to note is that when executing x86 instructions, one must be able to efficiently handle 8, 16, and 32-bit operands. If one is trying to execute multiple x86 instructions in parallel, it is not enough to simply multi-port the register file. This is because there are too few registers and all important program variables must be held in memory on the stack or in a fixed location.

Processor 500 achieves the affect of a large register file by multi-porting stack relative operations on the x86. Specifically, ESP or EBP relative accesses are detected, and upon a load or store to these regions a 32 byte data cache line is moved into an on-chip multi-port structure.

This structure is called a stack relative cache or stack cache (see FIG. 5). It contains a number of 32 byte cache lines that are multi-ported such that every issue position can simultaneously process a load or store. The accesses allowed are 8/16/32 bit accesses. 16 and 32-bit accesses are assumed to be aligned to natural boundaries. If this is not true, the access will take 2 consecutive cycles. The final optimization is that this structure for reads is contained in an early decode stage, the same stage that normal register file access is contained. Memory locations are also renamed so that speculative writes to the stack can be forwarded directly to subsequent operations.

The stack cache has two ports for each issue position. One port is for a load, and one port is for a store. Up to 8 cache lines, or 64 32-bit registers can be cached. Each 32-bit register can have 6 concurrent accesses. These cache lines are not contiguous, and the replacement algorithm for each cache line is LRU based. Unaligned accesses are handled as consecutive sequences of 2 reads and/or 2 writes, stalling, issue from that position until completion. The resulting two read accesses or write accesses are merged to form the final 16 or 32-bit access.

Thus an operation such as ADD EAX, EBP+d8!=EBP+d8! is encoded as one issue position. The load and store operations occur to the stack relative cache and not to the data cache. Up to 6 of these operations can issue in one clock cycle, and up to 6 operations can retire in one cycle. Also operations such as push that imply a store operation and a ESP relative decrement are directly executed, and multiple of these operations are allowed to occur in parallel.

FIG. 8 is a block diagram which shows the speculative hardware for the stack relative cache 520. Part of the first two pipeline stages decodes the accelerated subset and calculates the base pointer or stack pointer relative calculations to form the linear address before reaching the pipeline stage that accesses the stack relative register file and the line oriented reorder buffer. This will be discussed in greater detail below.

RISC designs employ regular instruction decoding along natural boundaries to achieve very high clock frequencies and also with a small number of pipeline stages even for very wide issue processors. This is possible because finding a large number of instructions and their opcodes is relatively straightforward, since they are always at fixed boundaries.

As stated previously, this is much more difficult in an x86 processor where there are variable byte instruction formats, as well as prefix bytes and SIB bytes that can effect the length and addressing/data types of the original opcode.

Processor 500 employs hardware to detect and send simple instructions to fixed issue positions, where the range of bytes that a particular issue position can use is limited. This may be compensated for by adding many issue positions that each instruction cache line can assume in parallel.

Once the instructions are aligned to a particular issue position, the net amount of hardware required to decode common instructions is not significantly greater than that of a RISC processor, allowing equivalent clock frequencies to be achieved. Processor 500 achieves high frequency, wide issue, and limited pipeline depth by limiting the instructions executed at high frequency to a sub-set of the x86 instructions under the conditions of 32-bit flat addressing.

Supporting a load/store memory architecture is possible within the constraints of the x86 instruction set if one redefines the meaning of register and memory. The reason for this redefinition is the x86 needs more than 8 resisters for optimal performance. The high performance RISC architecture use their large multi-ported register files to hold commonly referenced variables or constants. Thus, the inherently slower memory accesses can be limited to load and store operations, and the RISC can concentrate on building very wide issue hardware that executes directly on register/register operations.

As previously noted, many of the advantages of a large RISC register file can be achieved by multi-porting stack relative memory references, and keeping these structures in a multi-ported RAM array that can be read and written in the same pipeline stages as a register file on a RISC. There is also an advantage if these accesses are aligned to natural 16/32-bit boundaries, which is similarly a benefit to all existing x86 processors.

All operations that use this stack addressing subset can be treated as register like instructions that can be speculatively executed identical to the normal x86 registers. The remaining memory accesses may then be treated as being load/store operations by supporting these through access to a conventional data cache, but where the data cache is pipelined and performs accesses at accelerated clock frequencies.

Hardware detects and forwards memory calculations that hit in the current entries in the stack relative cache since it is possible for addressing modes outside of stack relative accesses to indirectly point to this same region of memory, and the stack cache is treated as modified memory. Because memory operations are a part of most x86 instructions, load/op/store operations may be converted to single issue operations. Processor 500 does this by allowing a single issue to contain as many as three distinct operations. If memory load and store operations outside of the stack relative cache are detected in decode, the pending operation is held in a reservation station, and the load access and addressing calculation are sent the multi-ported data cache. Upon completion of the load operation the reservation station is allowed to issue to the functional unit. Upon completion of execution, the result is either an x86 register or a pending store.

In either case the result is returned as completed to the entry in the reorder buffer. If a store, the store is held in speculative state in front of the data cache in a store buffer, from which point it can be speculatively forwarded from. The reorder buffer then can either cancel this store or allow it to writeback to the data cache when the line is retired.

All accesses to the stack relative cache can be renamed and forwarded to subsequent operations, identical to registers. This also includes references that are made as indirect non-stack relative accesses that store to the stack relative cache.

FIG. 9 is a block diagram which illustrates portions of an exemplary embodiment of processor 500 in greater detail. This structure is assumed to be capable of reading two data elements and writing two data elements per clock cycle at the accelerated clock frequency. Note that a mechanism must be maintained to allow the load and store operations to execute and forward speculatively while maintaining true program order.

The following set of instructions probably comprise 90% of the dynamically executed code for 32-bit applications:

8/32-bit operations

move reg/reg reg/mem

arithmetic operations reg/mem reg/reg logical operations reg/reg reg/mem push

logical operations reg/reg reg/mem

push

pop

call/return

load effective address

jump cc

jump unconditional

16-bit operations

prefix/move reg/reg

prefix/move reg/mem

prefix/arithmetic operations reg/reg, reg/mem

prefix/logical operations reg/reg reg/mem

prefix/push

prefix/pop

When executing 32-bit code under flat addressing, these instructions almost always fall within 1-8 bytes in length, which is in the same rough range of the aligned, accelerated fast path instructions.

FIG. 10 is a block representation of the alignment and decode structure of processor 500. This structure uses the instruction pre-decode information contained within each cache line to determine where the start and end positions are, as well as if a given instruction is an accelerated instruction or not.

Accelerated instructions are defined as fast-path instructions between 1 and 8 bytes in length. It noted that it is possible that the start/end positions predecoded reflect multiple x86 instructions, for instance 2 or 3 pushes that are predecoded in a row may be treated as one accelerated instruction that consumes 3 bytes.

When a cache line is fetched from the instruction cache, it moves into an instruction alignment unit which looks for start bytes within narrow ranges. The instruction alignment unit uses the positions of the start bytes of the instructions to dispatch the instructions to six issue positions. Instructions are dispatched such that each issue position accepts the first valid start byte within its range along with the next three bytes.

Four bytes is the maximum number of bytes which can include the prefix and opcode bytes of an instruction. A multiplexer in each decoder looks for the end byte associated with each start byte, where an end byte can be no more than seven bytes away from a start byte. The mechanism to scan for a constant value in an instruction over four bytes in length is given an extra pipeline stage due to the amount of time potentially required.

Note that instructions included in the subset of accelerated instructions, and which are over four bytes in length, always have a constant as the last 1/2/4 bytes. This constant is usually not needed until the instruction is issued to a functional unit, and therefore the determination of the constant value can be delayed in the pipeline. The exception is an instruction requiring an eight-bit displacement for an address calculation. The eight-bit displacement for stack-relative operations is always the third byte after the start byte, so this field will always be located within the same decoder as the rest of the instruction.

It is possible that a given cache line can have more instructions to issue than can be accommodated by the six entry positions contained in each line of the line-oriented reorder buffer. If this occurs, the line-oriented reorder buffer allocates a second line in the buffer as the remaining instructions are dispatched. Typically, in 32-bit application and O/S code, the average instruction length is about three bytes. The opcode is almost always the first two bytes, with the third byte being a sib byte specifying a memory address (if included), and the fourth byte being a 16-bit data prefix.

The assumption in the processor 500 alignment hardware is that if the average instruction length is three, then six dedicated issue positions and decoders assigned limited byte ranges should accommodate most instructions found within 16-byte instruction cache lines. If very dense decoding occurs (i.e., lots of one and two byte instructions), several lines are allocated in the line-oriented reorder buffer for the results of instructions contained in a few lines of the instruction cache. The fact that these more compact instructions are still issued in parallel and at a high clock frequency more than compensates for having some decoder positions potentially idle.

As an example, take the case of 8 two-byte instructions continually encoded within a cache line. This instruction sequence would have start bytes at positions:

FIG. 11 shows the cycle during which each instruction would be decoded and issued, and to which issue positions each instruction would be dispatched. Note that the instruction alignment unit uses no other advanced knowledge except the locations of the start bytes of each instruction. Entry positions in the line-oriented reorder buffer which correspond to issue positions which are not used during a given cycle are invalidated, and a new line is allocated in the line-oriented reorder buffer each cycle. This allows us to decode and align instructions at high speed without specifically knowing whether a given issue position is allocated an instruction in a given cycle.

A worst-case scenario might be a sequence of one-byte instructions (e.g., inc, push, inc, push, etc.). FIG. 12 shows the cycle during which each instruction would be decoded and issued, and to which issue positions each instruction would be dispatched. While the performance isn't spectacular, sequences of one-byte instructions are probably rarely encountered in code. The important point is that the mechanism does not break. Code typically contains two-byte, three-byte, and four-byte instructions mixed with one-byte instructions. With this mix, the majority of issue positions are allocated instructions. Long six-byte instructions are also rare, but if encountered, they are also directly executed.

FIG. 13 shows an example instruction sequence based on exemplary 32-bit application code. FIG. 14 shows the cycle during which each instruction would be decoded and issued, and to which issue positions each instruction would be dispatched. In this example, all branches are assumed not taken. Focusing on cycles 1-6 of FIG. 14, 26 x86 instructions are decoded/issued in six clock cycles. This reduces to 4.33 raw x86 instructions per clock cycle with this alignment technique.

FIG. 15 illustrates processor 500 pipeline execution cycles with a branch misprediction detected during cycle 6 and the resulting recovery operation. FIG. 16 similarly illustrates the processor 500 pipeline execution cycles for the equivalent seven stages assuming successful branch prediction and all required instruction and data present in the respective caches.

Description of Instruction Cache and Fetching Mechanism

Next the instruction cache organization, fetching mechanism, and pre-decode information will be discussed. As shown in FIGS. 17-20, the instruction cache (Icache) 502 of processor 500 includes blocks ICSTORE, ICTAGV, ICNXTBLK, ICCNTL, ICALIGN, ICFPC, and ICPRED. The instruction cache contains 32K bytes of storage and is an 8-way set associative cache, and is linearly addressed. The Icache is allowed more than one clock cycle to read and align the instructions to the decode units. The address is calculated in first half of ICLK, the data, tag, pre-decode, and predicting information are read in by the end of ICLK. In the next cycle, and the data are multiplexed from the tag comparison, and the instructions are aligned and sent to the decode units. The alignment multiplexing is accomplished as the tags are compared. The decode units can start decoding in the second half of this clock. The Icache includes a way-prediction which can be done in a single clock using the ICNXTBLK target. The branch prediction includes bimodal and global branch prediction which takes two clock cycles.

Table 6. Signal List

IRESET--Global signal used to reset ICACHE block. Clears all state machines to Idle/Reset.

IDECJAMIC--Global signal from the LOROB. Used to indicate that an interrupt or trap is being taken. Effect on Icache is to clear all pre-fetch or access in progress, and set all state machines to Idle/Reset.

SUPERV--Input from LSSEC indicates the supervisor mode or user mode of the current accessed instruction.

TR12DIC--Input from SRB indicates that all un-cached instructions must be fetched from the external memory.

SRBINVILV--Input from SRB to invalidate the Icache by clear all valid bits.

INSRDY--Input from BIU to indicates the valid external fetched instruction is on the INSB(63:0) bus.

INSFLT--Input from BIU to indicates the valid but faulted external fetched instruction is on the INSB(63:0) bus.

INSB(63:0)--Input from external buses for fetched instruction to the Icache.

REMAP--Input from L2 indicates the instruction is in the Icache with different mapping. The L2 provides the way associative and new supervisor bit. The LV will be set in this case.

PFREPLCOL(2:0)--Input from L2 indicates the way associative for writing of the ICTAGV.

UPDFPC--Input from LOROB indicate that a new Fetch PC has been detected. This signal accompanies the FPC for the Icache to begin access the cache arrays.

TARGET(31:0)--Input from LOROB as the new PC for branch correction path.

BRNMISP--Input from the Branch execution of the FU indicates that a branch mis-prediction. The Icache changes its state machine to access a new PC and clears all pending instructions.

BRNTAKEN--Input from the LOROB indicate the status of the mis-prediction. This signal must be gated with UPDFPC.

BRNFIRST--Input from the LOROB indicate the first or second target in the ICNXTBLK for updating the branch prediction.

BRNCOL(3:0)--Input from the LOROB indicates the instruction byte for updating the branch prediction in the ICNXTBLK.

FPCTYP--Input for the LOROB indicates the type of address that is being passed to the Icache.

BPC(11:0)--Input from the LOROB indicates the PC index and byte-pointer of the branch instruction which has been mis-predicted for updating the ICNXTBLK.

MVTOSRIAD--Input from SRB, indicates a move to IAD special register, Icache needs to check its pointer against the pointer driven on IAD.

MVFRSRIAD--Input from SRB, indicates a move from IAD special register, Icache needs to check its pointer against the pointer driven on IAD.

MVTOARIAD--Input from SRB, indicates a move to IAD special register array, Icache needs to check its pointer against the pointer driven on IAD.

MVFRARIAD--Input from SRB, indicates a move from IAD special register array, Icache needs to check its pointer against the pointer driven on IAD.

RTOPPTR(2:0)--Input from decode indicates the current top-of-the-stack pointer for the return stack. This information should be kept in the global shift register in case of mis-predicted branch.

RETPC(31:0)--Input from decode indicates the PC address from the top of the return stack for fast way prediction.

INVBYTE(3:0)--Input from Idecode to ICPRED indicates the starting byte position of the confused instruction for predecoding.

INVPRED--Input from Idecode to ICPRED indicates predecoding for the confused instruction.

INVPOLD--Input from Idecode indicates pre-decoding for the previous line of instruction. The ICFPC should start with the previous line.

REFRESH2--Input from Idecode indicates current line of instructions will be refreshed and not accept new instructions from Icache.

MROMEN--Input from MROM indicates the micro-instructions is sent to Idecode instead of the Icache.

RETPTR(2:0)--Output indicates the old pointer of the return stack from the mis-predicted branch instruction. The return stack should use this pointer to restore the top-of-the-stack pointer.

ICPC(31:0)--Output from Idecode indicates the current line PC to pass along with the instruction to the LOROB.

ICPOS0(3:0)--ICLK7 Output to decode unit 0 indicates the PC's byte position of the instruction.

ICPOS1(3:0)--ICLK7 Output to decode unit 1 indicates the PC's byte position of the instruction.

ICPOS2(3:0)--ICLK7 Output to decode unit 2 indicates the PC's byte position of the instruction.

ICPOS3(3:0)--ICLK7 Output to decode unit 3 indicates the PC's byte position of the instruction.

ICPOS4(3:0)--ICLK7 Output to decode unit 4 indicates the PC's byte position of the instruction.

ICPOS5(3:0)--ICLK7 Output to decode unit 5 indicates the PC's byte position of the instruction.

IBD0(31:0)--ICLK7 Output to decode unit 0 indicates the 4-byte of the instruction.

IBD1(31:0)--ICLK7 Output to decode unit 1 indicates the 4-byte of the instruction.

IBD2(31:0)--ICLK7 Output to decode unit 2 indicates the 4-byte of the instruction.

IBD3(31:0)--ICLK7 Output to decode unit 3 indicates the 4-byte of the instruction.

IBD4(31:0)--ICLK7 Output to decode unit 4 indicates the 4-byte of the instruction.

IBD5(31:0)--ICLK7 Output to decode unit 5 indicates the 4-byte of the instruction.

IC0START

IC1START

IC2START

IC3START

IC4START

IC5START--ICLK7 Output to Idecode indicates the start-byte for the lines of instructions being fetched.

IC0END(3:0)

IC1END(3:0)

IC2END(3:0)

IC3END(3:0)

IC4END(3:0)

IC5END(3:0)--ICLK7 Output to Idecode indicates the end-byte for the lines of instructions being fetched.

IC0FUNC(3:0)

IC1FUNC(3:0)

IC2FUNC(3:0)

IC3FUNC(3:0)

IC4FUNC(3:0)

IC5FUNC(3:0)--ICLK7 Output to Idecode indicates the functional-bit for the lines of instructions being fetched.

ICSTART(15:0)--ICLK7 Output to MROM indicates the start-byte for the lines of instructions being fetched.

ICEND(15:0)--ICLK7 Output to MROM indicates the end-byte for the lines of instructions being fetched.

ICFUNC(15:0)--ICLK7 Output to MROM indicates the functional-bit for the lines of instructions being fetched.

ICBRN1--ICLK7 Output, indicates the branch taken prediction of the first target in the ICNXTBLK for the lines of instructions being fetched.

ICBRN2--ICLK7 Output, indicates the branch taken prediction of the second target in the ICNXTBLK for the lines of instructions being fetched.

ICBCOL1(3:0)--ICLK7 Output, indicates the column of the first branch target in the ICNXTBLK for the lines of instructions being fetched.

ICBCOL2(3:0)--ICLK7 Output, indicates the column of the second branch target in the ICNXTBLK for the lines of instructions being fetched.

BTAG1(3:0)--Output indicates the position of the first target branch instruction with respect to the global shift register in case of branch mis-prediction.

BTAG2(3:0)--Output indicates the position of the second target branch instruction with respect to the global shift register in case of branch mis-prediction.

ICERROR--ICLK7 Output, indicates an exception has occurred on an instruction pre-fetched, the type of exception (TLB-miss, page-fault, illegal opcode, external bus error) will also be asserted.

INSPFET--Output to BIU and L2 requests instruction fetching from the previous incremented address, the pre-fetch buffer in the Icache has space for a new line from external memory.

ICAD(31:0)--ICLK7 Output to MMU indicates a new fetch PC request to external memory.

ICSR(31:0)--Input/Output to special registers indicates reading/writing data into the array for testing purpose.

IBTARGET(31:0)--Output to decode unit indicates the predicted taken branch target for the line on instruction in the previous cycle.

RETPRED--Output from Idecode indicates the current prediction of the return instruction of the fetched line. The return instruction must be detected in the current line of instruction or the Icache must be re-fetched from a new line.

ICSTORE

As stated previously, processor 500 executes fast path instructions directly. Three pre-decode bits are associated with each byte of instruction: a start bit, an end bit, and a functional bit. All the external fetched instructions will be latched into the Icache. Only single-byte prefixes of 0x66 and 0x0F are allowed for fast path instructions. Instructions including a second prefix byte of 0x67 are also allowed, and require one extra decode cycle. All other prefixes require extra cycles in decoding or execution using microcode sequences stored in MROM. With these simple prefixes, the instruction bytes need not be modified. The linear valid bit is used for the whole cache-line of instructions (16 bytes). The replacement procedure is controlled by the L2 unit. Along with each line of instruction, the L2 unit directs the Icache on storing the data and tag. The start and end bits are sufficient to validate the instruction. In cases of branching to the middle of a line or instructions which wrap around to the next line, the start and end bits must be detected for each instruction or else the instruction must be pre-decoded again. The possible cases are branching to the opcode and skipping the prefix (pruning of the instruction) and replacing part of the instruction in the Icache. The instructions must first be passed through pre-fetch buffers before being sent to the ICPRED. The ICPRED has only one input from the IB(127:0) for both the pre-fetched or cached instructions. The pre-decode information is written into the ICPDAT as the whole line is decoded.

Since the instruction fetching from external memory will be written directly into the Icache, the pre-fetch buffer should be built into the ICSTORE; the input/output path of the array. In this way, the data will be written into the Icache regardless of the pre-decode information or the taken branch instruction and the instructions are available to the Icache as soon as they are valid on the bus. There may be two pre-fetch buffers, and requests will be made to the BIU as soon as there is space in pre-fetch buffer for another line of instructions. The pre-fetch buffer includes a counter and a valid bit for instructions written into the cache, as well as a valid bit for instructions sent to the decode unit. As long as the address pointer is still in the same block, the data will be written to the array. With the pre-fetch buffer in the Icache, a dedicated bus should be used to transfer instructions directly from the pads to the Icache; this is a step to keep processor 500 from using dynamic precharged buses.

ICSTORE Organization

The ICSTORE in processor 500 does not include the predecode data. The ICSTORE contains 32K bytes of instructions organized as 8 sets of 128 rows by 256 columns. Each of the sets consist of two bytes of instructions. The 8-way associative multiplexing from the 8 TAG-HITs is performed before the data is routed to the ICALIGN block. With this arrangement, the input/output to each set is 16-bit buses. The multiplexing information regarding which byte is to be directed to which decode unit should also be decoded; this topic will be discussed in more detail in the ICALIGN section. For optimal performance, the layout of the column should be 64 RAM cells, precharge, 64 RAM cells, write buffer, and senseamp. The row decoder should be in the middle of the array to drive 128 columns each way, and the precharge and the row decoder should cross in the middle of the array. The self-time column is used to generate internal clock signals for each set of the array. The precharge is gated by the ICLK signal. The instruction is valid by the end of ICLK, the data multiplexed by the TAGHIT signals should be gated by ICLK to be valid for the second ICLK. The two-entry pre-fetch buffers are implemented inside the array with data input from either entry. The output IB bus is driven by either the array or the pre-fetch buffer.

Table 7. Signal List

IADD(11:0)--Input from ICFPC indicates the address of instruction to access the array. Bits 11:5 are for the row decoder, bits 4:0 are for column select.

TAGHIT(7:0)--Input from ICTAGV indicates which set is selected to read instructions.

ICSRD--Input from ICCNTL to read instruction.

ICSWR--Input from ICCNTL to write instructions from prefetch buffers into the array.

SRSRD--Input from ICCNTL to read instruction for special register.

SRSWR--Input from ICCNTL to write instruction for special register.

SETSEL(7:0)--Input from ICFPC indicates which set to read, no tag compare is needed.

TAGCHK--Input from ICCNTL to indicates the valid set is from TAGHIT or SETSEL.

PBENAB--Input from ICCNTL to enable the pre-fetch buffer to latch the INSB(31:0) bus and write into the array.

INSB(63:0)--Input from external buses for fetched instruction to the Icache.

IB(127:0)--Output to ICALIGN after the set select to align instructions to decode units.

PBFLT--Output to ICCNTL indicates the current instruction is faulted from external fetch.

PBVAL--Output to ICCNTL indicates the current instruction is valid from external fetch.

may be in the ICCNTL

PBEMPTY--Output to ICCNTL indicates the pre-fetch buffer is empty.

PBONE--Output to ICCNTL indicates the pre-fetch buffer has one available entry.

PBFULL--Output to ICCNTL indicates the pre-fetch buffer is full.

ICPDAT

In processor 500, the pre-decode data is stored in the ICPDAT section, not in the ICSTORE. The pre-decode data is updated with a different timing than that of instructions. The ICPDAT will be updated as the whole instruction line is completed decoding in the ICPRED. As instructions are written from pre-fetch buffer to the ICSTORE array, zeros will be written into the ICPDAT array to prevent future erroneous access. The pointer to ICSTORE will not advance until the whole line of instruction is pre-decoded and the ICPDAT array is updated. The control unit should allow the ICPDAT one clock cycle for updating before jumping to the next block. The pre-decode data includes three bits: start bit, end bit, and functional bit. Any valid instruction should begin with start-byte (with its start bit set) and end with the end-byte (with its end bit set) before the next start-byte is encountered. The start-byte and the end-byte are used to align the instructions from the ICSTORE to the decode units. The start bits are decoded into byte-shifting information which will be used by the ICALIGN block. The byte-shifting logic uses the following rules:

If the start byte is at byte location 0, the byte would be dispatched to decode unit 0. A given start byte will be dispatched to the lowest-ordered decoding unit possible not taken by the previous start byte. If a byte cannot be sent to any decode unit, then the rest of the line must wait for the next cycle to be dispatched to the decode units. In the next cycle, all the start bytes up to this byte should be clear, the first valid byte should go to the lowest-ordered decode unit possible. The last instruction of the line may wrap around to the next line if no end byte is detected. For example, if only three bytes of an instruction more than three bytes long is dispatched to decode unit 6, then decode unit 6 should not encounter an end byte. The logic for the alignment shifting is constructed with the maximum path of seven gates, the last gate of which is an inverter which can be included in the multiplexing of data. Two simplifications are made to eliminate the required scan through all the bytes:

1. At byte position 9, scan back to bytes 6-8. If there is a start byte in bytes 6-8, regardless of which decode unit is used, then byte 9 uses decode unit 4, else uses decode unit 3.

2. At byte position 12, scan back to bytes 9-11. If there is a start byte in bytes 9-11, regardless of which decode unit is used, then byte 12 uses decode unit 5, else uses decode unit 4.

The predecode bits are sent along with the instructions to the decode units. If a part of the line cannot be dispatched to the decode units, no start-byte is sent for that part of the line. The IBDx buses can be pseudo-dynamic buses with precharge using the self-time clock of the array. If the first byte of the decode unit does not have a start-byte, the decode unit passes a NOOP to the functional unit.

ICPDAT Organization

The ICPDAT contains 32K of 3-bit pre-decode data organized as 8 sets of 64 rows by 192 columns. Each of the sets consists of two 3-bit pre-decode data. The pre-decode data is decoded into byte-shifting information which is used by the ICALIGN block. The 8-way associative multiplexing from the 8 TAGHITs is performed before the byte-shifting data is routed to the ICALIGN block. In order for the instructions to get to the Idecode in middle of the second ICLK, the decode logic for the byte-shifting should be less than seven gates. Because of this byte-shifting logic, the array for ICPDAT is 64 rows instead of 128 rows for the ICSTORE array. For optimal performance, the layout of the column is 32 RAM cells, precharge, 32 RAM cells, write buffer and senseamp. The row decoder should be in the middle of the array to drive 96 column each way, and the precharge and the row decoder should cross in the middle of the array. The self-time column is used to generate internal clock signals for each set of the array. The precharge is gated by the ICLK signal. The byte-shifting data multiplexed by the TAGHIT should be gated by ICLK to be valid for the second ICLK. The output of the array should include logic to feedback the previous pre-decode data for breaking up of the line for second cycle access.

Table 8. Signal List

IADD(11:0)--Input from ICFPC indicates the address of instruction to access the array. Bits 11:6 are for the row decoder, bits 5:0 are for column select.

TAGHIT(7:0)--Input from ICTAGV indicates which set is selected to read instructions.

ICSRD--Input from ICCNTL to read instruction.

ICPWR--Input from ICCNTL to write predecoded data from ICPRED into the array.

SRPRD--Input from ICCNTL to read pre-decode data for special register.

SRPWR--Input from ICCNTL to write pre-decode data for special register.

SETSEL(7:0)--Input from ICFPC indicates which set to read, no tag compare is needed.

TAGCHK--Input from ICCNTL to indicates the valid set is from TAGHIT or SETSEL.

PSTARTB(7:0)--Input from ICPRED indicates the start bytes for current instruction. The start bytes are latched until pre-decoding of the whole line is completed.

PENDB(7:0)--Input from ICPRED indicates the end bytes for current instruction. The end bytes are latched until pre-decoding of the whole line is completed.

PFUNCB(7:0)--Input from ICPRED indicates the functional bytes for current instruction. The functional bytes are latched until pre-decoding of the whole line is completed.

PBYTEPTR(3:0)--Input from ICPRED indicates the byte position of the predecoded bytes for current instruction.

ICSTART(15:0)--ICLK7 Output to Idecode indicates the start-byte for the lines of instructions being fetched.

ICEND(15:0)--ICLK7 Output to Idecode indicates the end-byte for the lines of instructions being fetched.

ICFUNC(15:0)--ICLK7 Output to Idecode indicates the functional-bit for the lines of instructions being fetched.

BYTE0SH00--ICLK Output to ICALIGN indicates that byte 0 is shifted to byte 0 of decode 0.

BYTE1SH01--ICLK Output to ICALIGN indicates that byte 1 is shifted to byte 1 of decode 0.

BYTE2SH02--ICLK Output to ICALIGN indicates that byte 2 is shifted to byte 2 of decode 0.

BYTE3SH03--ICLK Output to ICALIGN indicates that byte 3 is shifted to byte 3 of decode 0.

BYTE1SH00

BYTE2SH01

BYTE3SH02

BYTE4SH03--ICLK Output to ICALIGN indicates that start-byte 1 and the next 3 bytes are shifted to decode 0.

BYTE2SH00

BYTE3SH01

BYTE4SH02

BYTE5SH03--ICLK Output to ICALIGN indicates that start-byte 2 and the next 3 bytes are shifted to decode 0.

BYTE6SH10

BYTE7SH11

BYTE8SH12

BYTE9SH13--ICLK Output to ICALIGN indicates that start-byte 2 and the next 4 bytes starting at byte 6 are shifted to decode 1.

BYTE1SH10

BYTE2SH11

BYTE3SH12

BYTE4SH13--ICLK Output to ICALIGN indicates that start-byte 1 and the next 3 bytes are shifted to decode 1.

BYTE2SH10

BYTE3SH11

BYTE4SH12

BYTE5SH13--ICLK Output to ICALIGN indicates that start-byte 2 and the next 3 bytes are shifted to decode 1.

BYTE3SH10

BYTE4SH11

BYTE5SH12

BYTE6SH13--ICLK Output to ICALIGN indicates that start-byte 3 and the next 3 bytes are shifted to decode 1.

BYTE4SH10

BYTE5SH11

BYTE6SH12

BYTE7SH13--ICLK Output to ICALIGN indicates that start-byte 4 and the next 3 bytes are shifted to decode 1.

BYTE3SH20

BYTE4SH21

BYTE5SH22

BYTE6SH23--ICLK Output to ICALIGN indicates that start-byte 3 and the next 3 bytes are shifted to decode 2.

BYTE4SH20

BYTESSH21

BYTE6SH22

BYTE7SH23--ICLK Output to ICALIGN indicates that start-byte 4 and the next 3 bytes are shifted to decode 2.

BYTE5SH20

BYTE6SH21

BYTE7SH22

BYTE8SH23--ICLK Output to ICALIGN indicates that start-byte 5 and the next 3 bytes are shifted to decode 2.

BYTE6SH20

BYTE7SH21

BYTE8SH22

BYTE9SH23--ICLK Output to ICALIGN indicates that start-byte 6 and the next 3 bytes are shifted to decode 2.

BYTE7SH20

BYTE8SH21

BYTE9SH22

BYTEASH23--ICLK Output to ICALIGN indicates that start-byte 7 and the next 3 bytes are shifted to decode 2.

BYTEBSH30

BYTECSH31

BYTEDSH32

BYTEESH33--ICLK Output to ICALIGN indicates that start-byte 7 and the next 4 bytes starting at byte 11 are shifted to decode 3.

BYTE8SH20

BYTE9SH21

BYTEASH22

BYTEBSH23--ICLK Output to ICALIGN indicates that start-byte 8 and the next 3 bytes are shifted to decode 2.

BYTECSH30

BYTEDSH31

BYTEESH32

BYTEFSH33--ICLK Output to ICALIGN indicates that start-byte 8 and the next 4 bytes starting at byte 12 are shifted to decode 3.

BYTE6SH30

BYTE7SH31

BYTE8SH32

BYTE9SH33--ICLK Output to ICALIGN indicates that start-byte 6 and the next 3 bytes are shifted to decode 3.

BYTE7SH30

BYTE8SH31

BYTE9SH32

BYTEASH33--ICLK Output to ICALIGN indicates that start-byte 7 and the next 3 bytes are shifted to decode 3.

BYTE8SH30

BYTE9SH31

BYTEASH32

BYTEBSH33--ICLK Output to ICALIGN indicates that start-byte 8 and the next 3 bytes are shifted to decode 3.

BYTE9SH30

BYTEASH31

BYTEBSH32

BYTECSH33--ICLK Output to ICALIGN indicates that start-byte 9 and the next 3 bytes are shifted to decode 3.

BYTEDSH40

BYTEESH41

BYTEFSH42--ICLK Output to ICALIGN indicates that start-byte 9 and the next 3 bytes starting at byte 13 are shifted to decode 4.

BYTEASH30

BYTEBSH31

BYTECSH32

BYTEDSH33--ICLK Output to ICALIGN indicates that start-byte 10 and the next 3 bytes are shifted to decode 3.

BYTEESH40

BYTEFSH41--ICLK Output to ICALIGN indicates that start-byte 10 and the next 2 bytes starting at byte 14 are shifted to decode 4.

BYTE9SH40

BYTEASH41

BYTEBSH42

BYTECSH43--ICLK Output to ICALIGN indicates that start-byte 9 and the next 3 bytes are shifted to decode 4.

BYTEASH40

BYTEBSH41

BYTECSH42

BYTEDSH43--ICLK Output to ICALIGN indicates that start-byte 10 and the next 3 bytes are shifted to decode 4.

BYTEBSH40

BYTECSH41

BYTEDSH42

BYTEESH43--ICLK Output to ICALIGN indicates that start-byte 11 and the next 3 bytes are shifted to decode 4.

BYTECSH40

BYTEDSH41

BYTEESH42

BYTEFSH43--ICLK Output to ICALIGN indicates that start-byte 12 and the next 3 bytes are shifted to decode 4.

BYTECSH50

BYTEDSH51

BYTEESH52

BYTEFSH53--ICLK Output to ICALIGN indicates that start-byte 12 and the next 3 bytes are shifted to decode 5.

BYTEDSH50

BYTEESH51

BYTEFSH52--ICLK Output to ICALIGN indicates that start-byte 13 and the next 2 bytes are shifted to decode 5.

BYTEESH50

BYTEFSH51--ICLK Output to ICALIGN indicates that start-byte 14 and the next 1 bytes are shifted to decode 5.

BYTEFSH50--ICLK Output to ICALIGN indicates that start-byte 15 is shifted to decode 5.

BYTEDSH60

BYTEESH61

BYTEFSH62--ICLK Output to ICALIGN indicates that start-byte 13 and the next 2 bytes are shifted to decode 6.

BYTEESH60

BYTEFSH61--ICLK Output to ICALIGN indicates that start-byte 14 and the next 1 bytes are shifted to decode 6.

BYTEFSH60--ICLK Output to ICALIGN indicates that start-byte 15 is shifted to decode 6.

NEXT2--ICLK Output to ICALIGN indicates break to next line starting from byte 2 and clears all pre-decode bits up to byte 2.

NEXT4--ICLK Output to ICALIGN indicates break to next line starting from byte 4 and clears all pre-decode bits up to byte 4.

NEXT5--ICLK Output to ICALIGN indicates break to next line starting from byte 5 and clears all pre-decode bits up to byte 5.

NEXT7--ICLK Output to ICALIGN indicates break to next line starting from byte 7 and clears all pre-decode bits up to byte 7.

NEXT8--ICLK Output to ICALIGN indicates break to next line starting from byte 8 and clears all pre-decode bits up to byte 8.

NEXTA--ICLK Output to ICALIGN indicates break to next line starting from byte 10 and clears all pre-decode bits up to byte 10.

NEXTD--ICLK Output to ICALIGN indicates break to next line starting from byte 13 and clears all pre-decode bits up to byte 13.

NEXTE--ICLK Output to ICALIGN indicates break to next line starting from byte 14 and clears all pre-decode bits up to byte 14.

NEXTF--ICLK Output to ICALIGN indicates break to next line starting from byte 15 and clears all pre-decode bits up to byte 15.

ICTAGV

As mentioned earlier, processor 500 executes the fast path instructions directly and the instructions are written into the Icache regardless of the pre-decode information. The linear valid bit is used for the whole line of instructions, assuming that the BIU always fetches 16 bytes, of data. The L2 unit directs placement of the pre-fetch data and tag. Writing of the tag and linear valid bit are done at the same time as writing the data into the ICSTORE. The start and end bits are sufficient to validate the instruction. If branching to the middle of the line or to instructions which wrap around to the next cache line, the start and end bytes must be detected for each instruction or else the instruction must be pre-decoded again. The possible cases for invalid instructions are (1) branching to the opcode and skipping the prefix, (2) part of an instruction which wraps around to the next cache line has been replaced in the Icache, (3) part of the line was not predecoded because it contained a branch instruction or branch target. Whenever the MMU is re-mapped or the L2 executes a certain instruction, all the LV bits can be cleared. The next access to the Icache would result in LV miss, the L2 may send new mapping information to the Icache regarding the way-associative, the SU, and the new tag. In this case the Icache needs to write the ICTAGV with new information (including setting the LV bit) and read the other arrays.

With respect to a branch prediction, the tag address must be read from the ICTAGV in the next cycle to merge with the successor index for the predicted target address. The predicted target address must be sent to the decode units and to the functional units for comparison.

ICTAGV Organization

The ICTAGV contains 2048 lines of:

1. 20-bit Tag address.

2. 2 Status bits (SU, LV).

The status bits need to be dual-port to read and write in the same clock cycle. The ICTAGV is organized as two sets of 64 rows by 224 columns and two sets of 64 rows by 128 columns. Each of the first two sets includes seven-bit tag addresses, and each of the last two sets includes three-bit tag addresses and the SU or LV bit. The two status bits are dual-port RAM cells. The SU uses the delayed PC to write, and the LV bit has the snooping index from L2. The ICTAGV uses 64 rows for dual-port RAM and quick reading of tag addresses. For optimal performance, the layout of the columns should be 32 RAM cells, precharge, 32 RAM cells, write buffer and senseamp. The row decoder should be in the middle of the array to drive 112 or 96 columns each way, and the precharge and the row decoder should cross in the middle of the array. The row decoder for the dual port RAM should be located at one end of the array. The self-time column is used to generate internal clock for each set of the array. The precharge is gated by the ICLK signal. The status bits multiplexed by the TAGHIT signal should be gated by the ICLK 59 signal to be valid for the second ICLK. The above layout is to ensure the minimum routing for the TAGHIT signal.

Table 9. Signal List

ITADD(11:4)--Input from ICFPC indicates the address of instruction to access the array. Bits 11:5 are for the row decoder, bit 4 is for column select.

IPADD(11:4)--Input from ICFPC indicates the address of instruction to access the LV array. Bits 11:5 are for the row decoder, bit 4 is for column select.

ICTAG(31:12)--Input from ICFPC indicates the address of instruction to compare with the tag arrays.

ICTVRD--Input from ICCNTL to read tag array.

ICTWR--Input from ICCNTL to write new tag.

ICVWR--Input from ICCNTL to write new valid bits.

ICCLRA--Input from ICCNTL to clear all valid bits.

ICSUWR--Input from ICCNTL to write the SU bit.

ICLVWR--Input from ICCNTL to write the LV bit.

SRTVRD--Input from ICCNTL to read tag for special register.

SRTVWR--Input from ICCNTL to write tag for special register.

SETSEL(7:0)--Input from ICFPC indicates which set to read, no tag compare is needed.

TAGCHK--Input from ICCNTL to indicates the valid set is from TAGHIT or SETSEL.

TAGHIT(7:0)--Output indicates which set is selected to read instructions.

VALBIT(7:0)--Output indicates the valid bits of 8 sets, uses for way-prediction.

VALBLK--Output indicates the valid block.

TVSU--Output indicates the supervisor/user mode of current block.

IBTARGET(31:0)--Output to decode unit indicates the predicted taken branch target for the line on instruction in the previous cycle.

ICNXTBLK

The ICNXTBLK block contains the branch prediction information for the Icache. FIG. 22 is a block diagram of the ICNXTBLK block. An important performance features of superscalar/superpilined microprocessors is branch prediction. As the number of pipeline stages and the number of functional units increases, the cost of branch mis-prediction is high. Processor 500 implements a branch prediction technique which picks one of the 8 ways from the previous line of instructions. Three bits are needed for this prediction. Another two bits are needed to select one of the two branch targets depending on the start-byte position in the next line. Without the two bits to select the branch targets, comparison of the start-byte position with the positions of the branch targets will cause the way-prediction to be more than one clock cycle. This speculative selection of a line of instructions can be corrected in the next cycle from the proper TAGHIT and the branch prediction. The following rules are used to set up the ICNXTBLK:

1) During pre-decode, if there is an unconditional branch instruction, it will take two clock cycles for the next target address to be calculated in the decode unit to update the PC. The pre-decode unit should continue to pre-decode instructions until the PC changes, the speculative way-prediction is updated with the successor index in the cycle following the target address access. If there is no unconditional branch, the speculative way-prediction is updated after fetching of the next block PC. The index after accessing the array should be kept for three clock cycles before the way-prediction is known for updating.

2) In the case of a branch mis-prediction, the new target PC is fetched, and the selected set and successor index are updated.

To improve the accuracies of branch predictions, the ICNXTBLK includes two branch targets and pre-decode unconditional branch instructions such as Unconditional Jump and CALL. The pre-decoding also calculates the branch target address for unconditional branch instructions if available. The RETURN instruction will be detected in the early phase of decoding. If there is a hit in the ICNXTBLK, the new target will be used for the new fetch PC. The taken branch will have higher priority to occupy the two branch target entries in ICNXTBLK.

Processor 500 implements two different branch predictors to maximize the performance. The next few sections discuss the Bimodal and Global predictors and the implementation of the combined branch predictor in processor 500.

Updating Branch Targets

Processor 500 employs an extra branch holding register for branch mis-predictions and pre-decoding branch instructions. The branch holding register should always be compared to the PC address and the contents of the branch holding register forwarded instead of reading from the ICNXTBLK. When the next branch mis-prediction occurs, the branch holding register will update the ICNXTBLK as the mis-prediction takes one cycle to send an address to the ICACHE. Another scenario during which to write the branch holding register into the ICNXTBLK array is when external fetch is started. With the branch holding register, the ICNXTBLK array can be single-ported. A single-ported array would take up less than half the size of a dual-ported array. The branch holding register includes the branch address which is used for comparison and forwarding of data, the successor index, the update branch predictor count, and the way-prediction after reading of the new target line. The branch address register resides in the ICFPC for comparison to the current fetch PC. The successor index, branch predictor counts, and the way-prediction are latched inside the ICNXTBLK to write into the array at a later convenient time. If the mis-prediction is a RETURN instruction, only the target selection of the way prediction should be updated. The global shift register and the return stack should restore the old value the same way.

Bimodal Branch Prediction

The bi-modal branch prediction method uses a saturated counter for prediction. Instead of a single bit prediction which indicates taken/non-taken, a two-bit counter is used for taken/non-taken prediction. The most significant bit determines the taken/non-taken prediction. Since branch instructions are more likely to be taken than non-taken, the counter should initialize to 10 if the branch target address can be calculated. If the branch is taken, the counter increases by 1 and saturates at 11. If the branch is not taken, the counter decrements by 1 to 01. A subsequent not-taken branch causes the counter to saturate at 00. The bimodal branch prediction is better than a single bit prediction as the branch correct prediction is 88.09% instead of 82.29% for two targets prediction based on tsim. The bimodal branch prediction performs well for mostly taken or non-taken branch instructions, and at worst flip-flops between taken and non-taken. The cost is one extra bit per branch target in the ICNXTBLK, and extra logic for the counter.

Global Branch Prediction

The global branch prediction method is an independent branch predictor, not a part of the Icache. FIG. 21 is a block diagram of the global branch predictor. Of the many different types of global branch prediction, processor 500 uses the global branch prediction which has the highest ratio of correct predictions. The prediction entries are indexed by an exclusive OR of the PC and the branch shift register. This global branch prediction has a correct prediction of 89.24% based on tsim; the prediction improves as more branch history bits are used in the prediction. A single shift register records the branches taken and not taken by the most recent n conditional branches. Since the branch history includes all branches, global branch prediction takes advantage of two types of patterns: 1) the direction taken by the current branch may depend strongly on the other recent branches, and 2) duplicating the behavior of local branch prediction (patterns of branches in loops). To match the number of entries in the Icache, the global branch prediction has 2048 entries with two targets per entry. It is organized with 256 rows of 8-way associative storage. Eighth bits are needed to index the branch prediction table. The PC uses bits 11:4 for indexing the branch prediction table.

Combined Branch Prediction

Combining the Bimodal and Global branch predictions should give a better correct prediction ratio. A predictor counter is used to select which branch predictor is better for each individual branch instruction. This technique should give a higher correct prediction ratio than the above two prediction techniques. The same saturated counter is used for the predictor counter. If the bimodal predictor is correct and the global predictor is incorrect then the counter is incremented until saturated. If the global predictor is correct and the bimodal predictor is incorrect, then the counter is decremented until saturated. In other cases, no change is made to the predictor counter. The most significant bit of the predictor counter is used as the branch predictor. ICNXTBLK is implemented with the bimodal counter and the predictor counter. ICNXTBLK has two targets per instruction line, each target consists of the following:

12 bits--successor index, need 11:4 for global table index, 11:0 for icache.

3 bits--for 8-way associative.

4 bits--byte position of the branch instruction within a line.

2 bits--bimodal counter

2 bits--predictor counter

The table for the global branch predictor also has two targets per entry, each entry consisting of a two-bit global counter. The bimodal and predictor counters must be updated on every cycle. The least significant bit of the counters is dual-ported. If the count is 10, the branch is predicted as taken, and the new count is 11. If the count is 01, the branch is predicted as not taken, and the new count is 00.

Implementation of Global Branch Prediction

As discussed above, the global branch predictor needs a table with 256 rows, 8-way associative storage, and two targets per line. An eight-bit shift register is needed for indexing. The global branch predictor shift register has to be able to back track to the previous mis-predicted conditional branch. As each conditional branch is predicted, the direction of the branch is shifted into the shift register from right to left, 1 for taken and 0 for not taken. The shift register is 24 bits long, and each of the bit positions beyond the eight indexing bits has a tag associated with it. The LOROB can handle up to 5 lines of instructions, and the pipeline from fetch to dispatch can hold another 3 lines of instructions. Each line of instructions can have up to two branch targets, which results in a maximum of 16 branch instructions in the pipeline. The shift register needs to keep track of all the conditional branch instructions. The extra 16 bits of the shift register is the maximum number of branches which can be predicted by eight lines of instructions. Four-bit tags are used for the 16 branch instructions. Each tag has three bits to indicate the line and one bit to indicate the first or second conditional branch prediction in the line. All the tags and the taken/not taken bits are shifted in the shift register. The shift register tag (branch tag) is routed with the branch instruction to the functional units and LOROB. If a branch instruction is mis-predicted, the branch tag is used to recover the old eight bits in the shift register for updating the prediction counter and supply the shift register with the new direction for the mis-predicted branch instruction. Along with the taken/not taken bits, the branch predictor count, the bimodal count, the global count, and the byte position should be kept in the same global shift register which will be restored for updating of the counters and the byte position in case of branch mis-prediction. The counters are six bits, the byte position is four bits, the branch tag is three bits, and one the taken/not taken bit; the total bits in the shift register is 14. The information will be restored and incremented/decremented to the holding register to update the mis-predicted block.

Way Prediction

Since the evaluation of the branch prediction takes two cycles, which would create a bubble in the pipeline, the way-prediction is implemented for faster prediction. The way prediction predicts which of the eight associative ways will be hit, and uses the ICNXTBLK for the next fetch PC. The way-prediction is validated in the next cycle with the TAGHIT and the actual branch prediction. If they are not the same, and the predicted set and the TAGHIT set are not both not taken, then the instruction line will be invalidated, creating a bubble in the pipeline.

The way-predicting has three bits used to multiplex the successor index and branch prediction from ICNXTBLK for accessing the Icache in the next cycle. Depending the current fetch PC's position, the way prediction can use one of the two branch targets or none for sequential. In order to access the next PC within a cycle, a target selection of two bits is needed. The target selection can also include the return stack option. The program for the target selection is:

1. 00--sequential,

2. 01--first branch target,

3. 10--second branch target,

4. 11--return stack.

The way prediction is dual port RAM cells because the information must be updated while reading data, the initial value for the way prediction should be the same as the current PC's set. The way prediction is not known for updating until three clock cycles later.

ICNXTBLK Organization

FIG. 22 shows a block diagram of the layout of ICNXTBLK. The ICNXTBLK includes 2048 lines of two branch targets, each target consist of 23 bits:

1. 12 bits--successor index, need 11:4 for global table index, 11:0 for icache.

2. 3 bits--for 8-way associative.

3. 4 bits--byte position.

4. 2 bits--bimodal counter.

5. 2 bits--predictor counter.

The ICNXTBLK also includes 2048 lines for way prediction which are dual ports:

1. 3 Way-prediction bits.

2. Target-selection bits.

The ICNXTBLK is organized as 5 sets of 64 rows by 256 columns, 1 set of 64 rows by 196 columns, 1 set of 64 rows by 96 dual-ported columns, and 1 set of 64 rows by 64 dual-ported columns. Each of the first two sets consists of 2.times.4 bits of successor index, the next two sets consists of 2.times.4 bits of successor index and 2.times.4 bits of the byte position, the next two sets consists of 2.times.2 bits bimodal counter, 2.times.2 bits predictor counter, and 2.times.3 bits 8-way associative, and the last two sets consist of the 3 bits way-prediction and two bits target selection which are dual-ported RAM cells. The least significant bits of the counters are dual-ported and updated on every cycle. To minimize routing and implementation of the branch holding register, the same associated bits of the two branch targets should be laid out in two sets opposite each other. The branch successor index is selected by the way and target prediction to access the ICACHE in next clock cycle. Because of this speed path in way prediction for reading the Icache in the next cycle, the array for ICNXTBLK is 64 rows instead of 128 rows as for the ICSTORE array. For optimal performance the layout of the column should be 32 RAM cells, precharge, 32 RAM cells, write buffer and senseamp. The row decoder should be in the middle of the array to drive 96 or 112 column each way, and the precharge and the row decoder should cross in the middle of the array. The self-time column is used to generate internal clock for each set of the array. Precharge is gated by ICLK. The ICNXTBLK has two different outputs; the first output in the first cycle is based on the way-prediction and the second output in the second cycle is based on TAGHIT. If the two outputs do not select the same set, or are not both not taken, the reading of instruction in the second cycle will be invalidated, creating a bubble in the pipeline. The second output should be gated with TAGHIT and ICLK to be valid in the second cycle. The way-prediction which uses the return stack may create a speedpath, depending on where the return stack is implemented.

The branch holding register is located in the ICNXTBLK array. This means that the bits of the two targets must be alternate in the array to access the branch holding register. The array may be skewed to accommodate the bits into a single array. The global branch counter is also implemented as the array in ICNXTBLK. The shift register and the branch tag for mis-prediction recovery are also implemented next to the array.

Table 10. Signal List

INADD(11:4)--Input from ICFPC indicates the address of instruction to access the array. Bits 11:5 are for the row decoder, bit 4 is for column select.

ICNVRD--Input from ICCNTL to read branch prediction array.

ICNWR--Input from ICCNTL to write branch prediction.

ICBCWR--Input from ICCNTL to write bimodal counter bits.

ICPSWR--Input from ICCNTL to write predictor counter bits.

SRNRD--Input from ICCNTL to read branch prediction for special register.

SRNWR--Input from ICCNTL to write branch prediction for special register.

STBYTE(3:0)--Input from ICFPC indicates the start byte position of the instruction, the position of the branch target must be greater than the start byte.

SETSEL(7:0)--Input from ICFPC indicates which set to read, no tag compare is needed.

TAGCHK--Input from ICCNTL to indicates the valid set is from TAGHIT or SETSEL.

TAGHIT(7:0)--Input from ICTAGV indicates which set is selected to read branch array.

RTOPPTR(2:0)--Input from decode indicates the current top-of-the-stack pointer for the return stack. This information should be kept in the global shift register in case of mis-predicted branch.

SINDEX(14:0)--Output indicates the successor index from branch prediction.

ICBRN1--ICLK7 Output, indicates the branch taken prediction of the first target in the ICNXTBLK for the lines of instructions being fetched.

ICBRN2--ICLK7 Output, indicates the branch taken prediction of the second target in the ICNXTBLK for the lines of instructions being fetched.

ICBCOL1(3:0)--ICLK7 Output, indicates the column of the first branch target in the ICNXTBLK for the lines of instructions being fetched.

ICBCOL2(3:0)--ICLK7 Output, indicates the column of the second branch target in the ICNXTBLK for the lines of instructions being fetched.

BTAG1(3:0)--Output indicates the position of the first target branch instruction with respect to the global shift register in case of branch mis-prediction.

BTAG2(3:0)--Output indicates the position of the second target branch instruction with respect to the global shift register in case of branch mis-prediction.

BTAKEN(1:0)--Output indicates branch taken from the msb of the bimodal count.

PSELECT(1:0)--Output from the msb of the predictor count, 1 indicates using the bimodal predictor, 0 indicates using the global predictor.

ICPSET(2:0)--Output to ICPFC indicates which set is predicted hit in the next cycle. The branch prediction and targets are used in the ICNXTBLK to access the next line.

ICPTAR(1:0)--Output to ICFPC indicates which branch target to use to access the cache in the next cycle. 00--sequential, 01--first branch target, 10--second branch target, and 11--return stack.

ICBTYP1(1:0)--ICLK7 Output, indicates the type of branch of the first target in the ICNXTBLK for the lines of instructions being fetched.

ICBTYP2(1:0)--ICLK7 Output, indicates the type of branch of the second target in the ICNXTBLK for the lines of instructions being fetched.

ICFPC

With an instruction address latch and incrementer in the ABI block, instruction addresses may be driven on the external address bus. This increases the performance of the DRAM access in burst mode. Continuous instruction address requests can be made by the Icache directly to the BIU without any handshaking. With a taken branch, the instruction address latch in the ABI block will be invalidated, and a new address must be sent to the MMU. The instruction address latch must detect page-boundary overflows (NAND gates for the lower bits of the address).

The ICFPC block contains all the current fetch PC logic, the PC incrementer for sequential access, and the branch holding address register for updating of the ICNXTBLK. The branch holding address register must always be compared to the PC to forward the branch data instead of reading from the ICNXTBLK.

The ICACHE uses linear addressing while the decode units use logical addressing. The code segment register is included in the ICFPC. The branch execution unit must calculate the linear address to send to ICACHE in case of branch mis-prediction. The ICACHE must subtract the base address of the code segment from the linear address to generate the logical address for the decode units. The translation is either for 16-bit addressing or 32-bit addressing, and either real or protected mode. The linear address can either be from the branch mis-prediction or the target tag-address of the successor index. The limit of the code segment register as sent to the decode units for calculation of segment violations. Generally speaking, the logical address should be less than the segment limit. The code segment register includes:

1. Segment selector (15:00)

2. Base Address 15:00, Segment Limit 15:00

3. Base Address 31:24, Control, Limit 19:16, Control, Type, Base Address 23:16

ICFPC Organization

The possible sources for index of ICSTORE are:

1. Incrementer of sequential address.

2. Refresh of current index.

3. Refresh the previous index because of confused instruction in decode.

4. Successor index of taken branch from way predictor of ICNXTBLK.

5. Return instruction target from way predictor of ICNXTBLK.

6. Corrected index of taken branch from branch prediction of ICNXTBLK.

7. Branch mis-prediction or Read-after-Write dependency flush from LOROB.

8. Special register reading/writing.

The possible sources for index of ICTAGV are:

1. Incrementer of sequential address.

2. Refresh of current index.

3. Refresh the previous index because of confused instruction in decode.

4. Next block address to check the cache during pre-fetching.

5. Successor index of taken branch from way predictor of ICNXTBLK.

6. Return instruction target from way predictor of ICNXTBLK.

7. Corrected index of taken branch from branch prediction of ICNXTBLK.

8. Branch mis-prediction or Read-after-Write dependency flush from LOROB.

9. L2 new mapping for current tag miss.

10. Special register reading/writing.

The possible sources for index of ICPDAT are:

1. Incrementer of sequential address for reading (same as ICSTORE).

2. Refresh of current index.

3. Refresh the previous index because of confused instruction in decode.

4. Delay of sequential address for writing of pre-decode data.

5. Successor index of taken branch from way predictor of ICNXTBLK.

6. Return instruction target from way predictor of ICNXTBLK.

7. Corrected index of taken branch from branch prediction of ICNXTBLK.

8. Branch mis-prediction or Read-after-Write dependency flush from LOROB.

9. Special register reading/writing.

The possible sources for index of ICNXTBLK are:

1. Incrementer of sequential address.

2. Refresh of current index.

3. Refresh the previous index because of confused instruction in decode.

4. Delay of sequential address for writing of predecode data.

5. Successor index of taken branch from way predictor of ICNXTBLK.

6. Return instruction target from way predictor of ICNXTBLK.

7. Corrected index of taken branch from branch prediction of ICNXTBLK.

8. Branch mis-prediction or Read-after-Write dependency flush from LOROB.

9. Branch holding address register.

10. Special register reading/writing.

The ICFPC block also includes the code segment register, the PC incrementer address, the branch holding address register and comparator, and the subtractor for calculation of logical address. The code segment register includes the base for logical address calculation and the limit for segment violation. The PC incrementer has two parts: the index incrementer and the tag-address incrementer. The tag-address incrementer is used only when the index incrementer is overflowed. It is much faster to break up the PC incrementer in two parts.

Table 11. Signal List

INVPOLD--Input from Idecode indicates pre-decoding for the previous line of instruction. The ICFPC should start with the previous line.

ICNEWBLK--Input from ICCNTL to read new sequential block.

ICNXTBLK--Input from ICCNTL to check next sequential block during pre-fetching.

WPTAKEN--Input from ICNXTBLK indicates taken branch from way prediction.

WPRET--Input from ICNXTBLK indicates the return instruction from way prediction.

BPTAKEN--Input from ICNXTBLK indicates taken branch from the correct branch prediction.

BRNMISP--Input from the Branch execution of the FU indicates that a branch mis-prediction. The Icache changes its state machine to access a new PC and clears all pending instructions.

MVSR--Input from ICCNTL indicates move-to special register instruction.

ICPWR--Input from ICCNTL to write predecoded data from ICPRED into the array.

ICNWR--Input from ICCNTL to write branch prediction.

WSINDEX(14:0)--Input from ICNXTBLK indicates the successor index from the way prediction.

BSINDEX(14:0)--Input from ICNXTBLK indicates the successor index from the correct branch prediction.

FPC(31:0)--Input from LOROB as the new PC for branch correction path.

RETPC(31:0)--Input from decode indicates the PC address from the top of the return stack for fast way prediction.

BRNMISP--Input from the Branch execution of the FU indicates that a branch mis-prediction. The Icache changes its state machine to access a new PC and clears all pending instructions.

BRNTAKEN--Input from the LOROB indicate the status of the mis-prediction. This signal must be gated with UPDFPC.

BRNFIRST--Input from the LOROB indicate the first or second target in the ICNXTBLK for updating the branch prediction.

BRNCOL(3:0)--Input from the LOROB indicates the instruction byte for updating the branch prediction in the ICNXTBLK.

FPCTYP--Input for the LOROB indicates the type of address that is being passed to the Icache.

BPC(31:0)--Input from the LOROB indicates the PC address of the branch instruction which has been mis-predicted for updating the ICNXTBLK.

CSREG(31:0)--Input from the LOROB indicates the new code segment register.

REMAP--Input from L2 indicates the instruction is in the Icache with different mapping. The L2 provides the way associative, new supervisor bit, and new tag address. The LV will be set in this case.

MTAG(31:12)--Input from L2 indicates the new tag to write into the ICTAGV.

MCOL(2:0)--Input from L2 indicates the way associative for writing of the ICTAGV.

ITADD(11:4)--Output to ICTAGV indicates the address of instruction to access the array. Bits 11:5 are for the row decoder, bit 4 is for column select.

IPADD(11:4)--Output to ICTAGV indicates the address of instruction to access the LV array. Bits 11:5 are for the row decoder, bit 4 is for column select.

ICLIMIT(19:0)--Output to decode units indicates the limit of the code segment register for segment violation.

ICPC(31:0)--Output from Idecode indicates the current line PC to pass along with the instruction to the LOROB.

ICPRED

The ICPRED block pre-decodes the instructions as they come in from the external memory or from the Icache if the start/end bits are not found where expected. FIG. 23 is a block diagram of the ICPRED block. In processor 500, the ICPRED is connected to the IB(127:0) to read the instructions from either the pre-fetch buffer or the Icache. For external fetched instructions, the ICPRED starts from the fetched byte position. The ICPRED latches the instructions in the second ICLK as they are sent to the decode units. If the start/end bits are not found where expected, then the decode units send the byte position of the invalid instruction to the ICPRED for pre-decoding. The pre-decoding is started from scratch in this case. The ICPRED takes two clock cycles to decode one instruction plus an extra clock cycle for any prefix bytes. The pre-decode information include start, end, and functional bits, as well as any branch prediction information. The rules for predecoding of instructions are:

1. Fast-path instructions should have at most only one prefix, OF or 66. For more than one prefix, all prefixes except for string prefixes, the instructions will take two clock cycles during decoding. For other prefixes, MROM execution will be specified.

2. Any instruction which is not in subset of fast path instructions should have the MROM opcode bit set. The fast path instruction subset includes:

PUSH

POP

CALL/RETURN

LEA

JUMP cc/unconditional

8/32-bit operations

MOVE reg/reg reg/mem

ALU operations reg/mem reg/reg (excluding the RCR and RCL instructions)

3. Decoding of CALL and Unconditional JUMP instructions may cause the predictor and the bimodal counters to become saturated in the ICNXTBLK. The branch target information is kept in the branch holding register for future updating. The ICPRED calculates the target address for the Unconditional JUMP if possible. Otherwise, fetching of instructions ceases until the target address is calculated during decoding or execution.

4. The RETURN instructions are also pre-decoded to access the return stack.

5. Decoding of Conditional JUMP instructions with backward branch will require the calculation of the target address. Since backward branches are mostly taken and the adder is available to calculate the target address, the conditional branch should be predicted taken. The taken branches have the higher priority to occupy the branch targets. Conditional branch instructions are needed for the global branch predictor; conditional branch instructions have a higher priority to occupy the branch target than CALL or Unconditional JUMP with 8-bit displacement linear addresses. The decode units decode the instructions for unconditional branches. If target addresses are simple calculations, the decode units calculate the target addresses. All branch instructions must be predecoded and assigned to the two targets in the ICNXTBLK.

If early decoding of a "two-cycle" fast path instruction is detected, the instruction line will be delayed into the next cycle starting with the two-cycle fast path instruction. The extra cycle is needed to combine the prefixes into one and locate the other fields of the instruction. To distinguish the three different cases of prefixes, the pre-decoding of the functional byte is as follows:

To ease instruction decoding later in the pipeline, the functional byte can encode more information regarding the opcode, MODRM, SIB, displacement, and immediate bytes quickly:

1. With start-byte, the functional byte is as discussed above.

2. Without start-byte, if the functional byte is set on second byte, it indicates that this second byte is opcode, the first byte (with start-byte) is prefix. If the functional byte is not set on second byte, the first byte is opcode.

3. Without start-byte, from third byte, if the functional byte is set, it indicates that this byte is displacement or immediate data. With 8-bit displacement, one functional byte is set, with 16-bit displacement, two consecutive functional bytes are set, with 32-bit displacement, 4 consecutive functional bytes are set. With this pre-decoding, the EBP+displacement can be calculated for any size of displacement. If there is no displacement field, the bit is set for the immediate field. In this case, the calculation of the assumed linear address by the decode unit can be invalidated by decoding of the MODRM byte. The setting of the immediate byte is important to detect the SIB byte in the instruction. The immediate data of the instruction can take more time in decoding and routing to the functional units.

ICPRED Organization

As shown in FIG. 23, the ICPRED includes three blocks. One block, ICPREFIX, decodes the prefix. Another block, ICDECINS, decodes the instruction. A third block, ICPREINS, sets up the pre-decode data. The ICPREFIX block decodes up to two prefix bytes per clock cycle. If there is more than one prefix byte and the prefix is not OF or 66, the first functional byte will signal an MROM instruction. The ICDECINS accepts prefix status and three instruction bytes; the opcode, the MODRM, and the SIB. In the first cycle, no prefix is assumed. If a prefix is detected in the ICPREFIX, the ICDECINS will restart the decoding of instruction with a new prefix status and three new instruction bytes. If more prefixes are detected in a subsequent cycle, the ICDECINS will restart the decoding with new information. After the decoding, the pre-decode information will be sent to the align logic and the latch in the ICPDAT. The ICPDAT will dispatch the appropriate instruction and pre-decode data to the decode unit. The byte pointer moves to the next instruction and the procedure continues until the whole line is completed. The writing of the ICPDAT will be accomplished when the whole line is decoded. The ICDECINS also decodes branch instructions and sets up the two targets in the ICNXTBLK. The ICDECINS includes an adder to calculate the simple taken branch addresses; PC+displacement. The ICPRED includes local latches of eight bytes for instruction which wrap around to the next line. For instructions longer than 15 bytes, an exception is asserted to the decode units. The outputs of the ICPREFIX and ICDECINS are directed to ICPREINS for analyzing and setting up the pre-decode data.

Table 12. Signal List

IB(127:0)--Input from ICSTORE indicates the line of instructions from the array or pre-fetch buffer for pre-decoding.

INVBYTE(3:0)--Input from Idecode indicates the starting byte position of the confused instruction for pre-decoding.

INVPRED--Input from Idecode indicates pre-decoding for the confused instruction.

BYTEPTR--Input from ICFPC indicates the current position of the line for pre-decoding.

PREDEN--Input from ICCNTL to enable the pre-decoding of instruction.

PSTARTB(7:0)--Output to ICPDAT and decode units indicates the start bytes for current instruction. The start bytes are latched until pre-decoding of the whole line is completed.

PENDB(7:0)--Output to ICPDAT and decode units indicates the end bytes for current instruction. The end bytes are latched until pre-decoding of the whole line is completed.

PFUNCB(7:0)--Output to ICPDAT and decode units indicates the functional bytes for current instruction. The functional bytes are latched until pre-decoding of the whole line is completed.

PBYTEPTR(3:0)--Output to ICPDAT indicates the byte position of the predecoded bytes for current instruction.

PBYTE(3:0)--Output to ICNXTBLK indicates the byte position for current branch instruction. The byte position is latched until pre-decoding of the whole line is completed.

PJMPI(1:0)--Output to ICNXTBLK indicates the type of branch instruction which is latched until pre-decoding of the whole line is completed.

PTAKEN--Output to ICNXTBLK indicates the current branch instruction is predicted taken. The initial prediction is to use the bimodal branch predictor. The taken prediction is latched until pre-decoding of the whole line is completed.

PTARGET(31:0)--Output to ICNXTBLK and ICFPC indicates the branch target for current branch instruction. The successor index is latched until pre-decoding of the whole line is completed. If the branch is taken, the way calculation is done in ICFPC and latched until branch mis-predictions or external fetch is started.

PBlX2--Output to ICNXTBLK indicates the first or second target in ICNXTBLK is updated for current branch instruction.

PJMPEN--Output to ICNXTBLK indicates the branch instruction predecoded.

ICALIGN

The function of the ICALIGN block is to use the predecode information and send the X86 instructions to the decode units as fixed length instructions of four-bytes or eight-bytes. FIG. 24 is a block diagram of how the ICALIGN function interfaces with other functions, and FIG. 25 is a block diagram of the ICALIGN function. The alignment works on the four-byte boundary, the shifting is based on the start/end byte information:

Each decode unit is capable of receiving four-byte instructions. Instructions from five to eight bytes in length can be handled using two successive decode units. Issue position 6 is only three-byte in length and is not real; issues position 6 is used for wrapping the instruction to decode unit 0 of the next line. Decode unit 5 is also able to wrap an instruction around to decode unit 0 of the next line. If an instruction has between five and eight bytes, then bytes five and up are contained in the next decode unit. It is noted that these extra bytes contain only immediate data or displacement data. Each decode unit has a by-pass path to send the data to the immediate or displacement registers of the previous decode unit. The instruction being decoded can also be invalidated and set to NOOP by the previous decode unit. If the incomplete instruction, in decode unit 4 or 5, starts with four or more bytes in the first line and the displacement byte is known, then the decode unit should decode the instruction. The rest of the instruction is immediate data which can be forward, skipping one clock cycle and proceeding directly to the LOROB. Otherwise, the instruction will be passed to decode unit 0 when the next line is decoded during the next clock cycle.

If a byte in byte position 0 is a start-byte, the byte would be dispatched to decode unit 0. As mentioned earlier, a start byte should be dispatched to the lowest-ordered decoding unit not taken by a previous start byte. If a byte cannot be sent to any decode unit, the rest of the line must wait for the next cycle to be dispatched to the decode units. In this case, all the start bytes up to the current start byte should be clear, and the first valid start byte should go to the lowest-ordered decode unit. The logic for the alignment shifting may be implemented using seven cascaded levels of logic gates. The last gate is an inverter which may be included in the data multiplexing circuit.

In order to help the decode units calculate the current PC, the relative byte position of each byte will be encoded into four bits and routed with the start-byte to the decode units. Each decode unit concatenates the PC with the four-position bit byte position for its PC address. This PC address can be used to calculate the relative taken branch address.

Only up to three instructions are allowed to start in byte locations 0-3; up to 4 instructions in byte locations 0-7 to 5 instructions in byte 0-11; and a maximum of 7 instructions can be dispatched in the entire line at one time. It is noted that if seven instructions are dispatched, the last instruction should not have the end-byte in the same cache line.

Examples of Fetching Mechanism

ICALIGN Organization

The ICALIGN function includes multiplexers for instructions and pre-decode data from ICACHE arrays to decode units. There are two levels of multiplexers; the first level is controlled by the TAGHIT, and the second level is controlled by the aligned logic in the ICPDAT. The first level of multiplexing is implemented within the ICSTORE and ICPDAT block. This block includes latches and logic to breakup the line for next cycle in case all instructions cannot be dispatched in the same clock cycle. The encoder for the start-byte position is needed to generate the relative address of the PC to the decode units.

Table 13. Signal List

REFRESH2--Input from Idecode indicates current line of instructions will be refreshed and not accept new instructions from Icache.

MROMEN--Input from MROM indicates the micro-instructions is sent to Idecode instead of the Icache.

IB(127:0)--Input from ICSTORE indicates the new line of instructions to be sent to decode units.

BYTExSHxx--Input from ICPDAT to control the multiplexes, see ICPDAT for details.

NEXTx--Input from ICPDAT to breakup the line, see ICPDAT for details.

BYTEP1(15:0)--Input from ICNXTBLK indicate the byte position of the first branch target.

BYTEP2(15:0)--Input from ICNXTBLK indicate the byte position of the second branch target.

ICSTART(15:0)--ICLK7 Output to Idecode indicates the start-byte for the lines of instructions being fetched.

ICEND(15:0)--ICLK7 Output to Idecode indicates the end-byte for the lines of instructions being fetched.

ICFUNC(15:0)--ICLK7 Output to Idecode indicates the functional-bit for the lines of instructions being fetched.

ICPOS0(3:0)--ICLK7 Output to decode unit 0 indicates the PC's byte position of the instruction.

ICPOS1(3:0)--ICLK7 Output to decode unit 1 indicates the PC's byte position of the instruction.

ICPOS2(3:0)--ICLK7 Output to decode unit 2 indicates the PC's byte position of the instruction.

ICPOS3(3:0)--ICLK7 Output to decode unit 3 indicates the PC's byte position of the instruction. ICPOS4(3:0)--ICLK7 Output to decode unit 4 indicates the PC's byte position of the instruction. ICPOS5(3:0)--ICLK7 Output to decode unit 5 indicates the PC's byte position of the instruction. IBD0(31:0)--ICLK7 Output to decode unit 0 indicates the 4-byte of the instruction. IBD1(31:0)--ICLK7 Output to decode unit 1 indicates the 4-byte of the instruction.

IBD2(31:0)--ICLK7 Output to decode unit 2 indicates the 4-byte of the instruction.

IBD3(31:0)--ICLK7 Output to decode unit 3 indicates the 4-byte of the instruction.

IBD4(31:0)--ICLK7 Output to decode unit 4 indicates the 4-byte of the instruction.

IBD5(31:0)--ICLK7 Output to decode unit 5 indicates the 4-byte of the instruction.

IC0START

IC1START

IC2START

IC3START

IC4START

IC5START--ICLK7 Output to Idecode indicates the start-byte for the lines of instructions being fetched.

IC0END(3:0)

IC1END(3:0)

IC2END(3:0)

IC3END(3:0)

IC4END(3:0)

IC5END(3:0)--ICLK7 Output to Idecode indicates the end-byte for the lines of instructions being fetched.

IC0FUNC(3:0)

IC1FUNC(3:0)

IC2FUNC(3:0)

IC3FUNC(3:0)

IC4FUNC(3:0)

IC5FUNC(3:0)--ICLK7 Output to Idecode indicates the functional-bit for the lines of instructions being fetched.

ICCNTL

The ICCNTL is the main state machine in the ICACHE. FIG. 26 shows an embodiment of the ICCNTL state machine. ICCNTL latches the inputs at the beginning of the ICLK signal and generates control signals to the arrays for the next cycle by the end of the ICLK cycle. A few signal from the arrays, such as TAGHIT, are issued to ICCNTL in early ICLK cycle instead of the previous phase. The state machine can be forced to transition to certain states with late arriving signals from branch mis-prediction and branch prediction. The IRESET forces the state machine to Idle state, initializes the code segment register, and clears the status of ICACHE. For external fetches, dedicated buses may exist for addresses to MMU and instructions from the pads. The state machine for external fetches is not needed in this case. The preliminary state machine definition and transitions are from the current definition of processor 500.

The ICCNTL block uses logic synthesis with special attention to the late arriving signals from the ICTAGV and ICNXTBLK arrays. Input and output signals are described in sections on other blocks. The ICCNTL should provide all the signals to read and write the cache arrays.

STATE0: Idle State

The Idle state is forced by IRESET, Branch Mis-prediction, or EXCEPTION, and waits for taken branch target. This is a default state. If the state is forced by branch mis-prediction, it provides Icache control signals to write the Branch Holding Register into the ICNXTBLK. This state transfers to the Cache Access state when the taken branch address is valid, the transfer provides all Icache control signals for reading the array.

STATE1: Cache Access State

The Icache is being accessed. The TAGHIT is not determined until next clock cycle. The assumption is HIT and access is from the next block. The next block address can either come from the ICNXTBLK or sequential. This state provides all Icache control signals for reading the array. When the TAGHIT is received, if there is no holding due to breaking up of the instruction line or invalid pre-decode data, then the state remains in Cache Access state. Otherwise, the state will transition to Cache Hold state. The transition to Cache Hold state provides all Icache control signals for reading the next block of the array. If a miss occurs in the Icache, the state machine transitions to the Cache Miss state. The miss can either be the tag or LV miss. The transfer to Cache Miss state provides Icache control signals to write the Branch Holding Register into the ICNXTBLK.

STATE2: Cache Hold State

This state is a wait state for the whole line of instructions to be dispatched to the decode units. All Icache control signals for reading of next block are continuously provided. As soon as the ICALIGN block can accept the next line, the state machine transitions to the Cache Access state.

STATE3: Cache Miss state

The Cache Miss state makes a request to the L2 and waits for a response. There are two different responses: the first response is the new mapping of the PC (the instructions, pre-decode data, and branch prediction are still valid), and the second response is the fetch of instructions from external memory. The new mapping of the PC includes setting of the LV bit and writing of new SU and tag. For the first case, the state is transferred to Recovery state, and the Icache control signals are to write the ICTAGV and read the ICSTORE, ICPDAT, and ICNXTBLK. For the second case, the state is transferred to the Pre-fetch state, and the Icache control signals are to write the ICTAGV and ICSTORE.

STATE4: Recovery state

The Recovery state is a transitional state before transitions to the Cache Access State. This state provides all Icache control signals for reading the array.

STATE5: Pre-fetch state

This state sends the instruction from the pre-fetch buffer to the ICPRED for pre-decoding. The pre-fetch buffer accepts instructions until full. Handshaking with the BIU occurs to stop fetching and to prevent overfilling the buffer. As the current line is written into the ICSTORE array, the pre-fetch buffer can shift in a new line. The writing of the new line must wait for the completion of pre-decoding of the current line. This state provides array control signals for writing of the ICSTORE array and reading of the next sequential block in the ICTAGV. If the next sequential block is present, as soon as the current line is completed in pre-decoding, the state transitions to the Pre-decode Write state. The array control signals for these transitions are writing of the ICPDAT and ICNXTBLK. If the next sequential block is not present, completion of the pre-decoding of the current line causes the Icache PC to increment and the writing of the new line into the ICSTORE, and restarts the pre-decoding of the new line. If there is an instruction which wraps to the new line, writing of the last line into the ICPDAT and ICNXTBLK must wait for completion of pre-decoding of this wrapped instruction. During pre-decoding, a taken branch can be detected, the state transitions to the Pre-decode Write state.

STATE6: Pre-decode Write state

This state is a transitional state to write the ICPDAT and the ICNXTBLK before transitions to the Idle state or Cache Access state. If the next block address is present from either sequential block or taken branch address which is calculated by the ICPRED, then the state transitions to the Cache Access state. The transfer provides all Icache control signals for reading the array. If the taken branch address cannot be calculated by the ICPRED, then the state transitions to the Idle state, waiting for the target address from decoding or executing of the instruction.

Timing

Since the processor clock cycle is reduced to 4.5 ns, reading of the cache takes an entire clock cycle to get data. The clock is single phase, and the array needs to generate its own self-time clock. The self-time clock uses the same cache column self-time line. As the line is precharged to a high level, the precharge is disabled and the array access is enabled. As the line is discharged, the row driver and senseamp are disabled. The precharge takes 1.7 ns and the current timing for TAGHIT from the self-time clock with 64 rows is 2.8 ns for a total time of 4.5 ns from rising edge of ICLK. The reading of data occurs 2.0 ns from the self-time clock with 64 rows or 0.8 ns before the rising edge of ICLK. The ICSTORE can be implemented using larger arrays, 128 rows by 256 columns. The reading of instructions would take all of 4.5 ns ICLK in this case. All other arrays, ICTAGV, ICPRED, and ICNXTBLK, are 64 rows. The align logic in the ICPDAT takes 6-7 gates, the shifting of X86 instruction bytes to the decode unit can be done by the middle of the second ICLK. The fast path instructions should allow the decode units at least 2.5 ns in the second ICLK for calculation of the linear address.

1. ICLK1: ICFPC, multiplexing new PC, precharge, and access all arrays

2. ICLK2.0: Compare tags, aligning logics from pre-decode, setup branch prediction, and multiplexing instructions to decode units on IB buses.

3. ICLK2.1: Displacement linear address calculation. Fast decoding for register operands and validating of the linear address, and fast decoding for non-conditional branch.

If the predicted branch from the ICNXTBLK is taken, the new PC will take two clock cycles to update in the ICFPC. The speculative way-prediction takes two gates for set decoding, three gates for multiplexing of success index to ICFPC, and two gates in row decoding.

The timing for instructions from external memory is as follows:

1. ICLK1: Latch data from INSB bus to pre-fetch buffer and multiplex onto IB buses to ICPRED in next clock; the data on IB buses are held until pre-decode is completed. Write data into cache.

2. ICLK2: Decode opcode and prefix from the byte pointer. Decoding takes two clock cycles. If there is prefix, then restart the decoding of opcode in the next cycle.

3. ICLK3: Decode opcode. Send pre-decode data to ICPDAT and allow the align logic to select the instruction on IB buses to decode units

4. ICLK4: Send instruction from IB buses to decode units on IBDx buses. The IBDx buses should have the same timing as reading from the array.

Layout

FIG. 27 is a block diagram of the Icache and fetching mechanism. With 4.5 ns ICLK, the size of the arrays are limited to 128 rows by 256 columns for single-port RAM arrays which read or write in different clock cycles and are not in the critical path. For dual-port RAM arrays or faster read timing, the 64 rows by 256 columns array are preferred. The array sizes are based on the single port RAM cell of 10.25 u.times.6.75 u, and the dual port RAM cell of 10.25 u.times.14.5 u. The arrays in the ICACHE are laid out as followed:

1. ICSTORE--2048 lines of 128 bits, 8 sets of 128.times.256, 1312 u.times.1728 u, single.

2. ICPREDAT--2048 lines of 48 bits, 8 sets of 64.times.192, 656 u.times.1296 u, single.

3. ICTAGV--2048 lines of 24 bits, 3 sets of 64.times.224, 656 u.times.1512 u, single, and 1 set of 64.times.96, 656 u.times.1392 u, dual.

4. ICNXTBLK--2048 lines of 51 bits, 5 sets of 64.times.256, 656 u.times.1728u, single, 1 set of 64.times.192, 656 u.times.1296 u, single, 1 set of 64.times.96, 656 u.times.1392 u, dual, and 1 set of 64.times.64, 656 u.times.928 u, dual.

ICTAGV includes a 20-bit tag, a 1-bit valid, a 3-bit status, and a 3-bit way-prediction. The tag and valid are single-port RAM, the status and way-prediction are dual-port RAM. The ICNXTBLK does not include the global branch prediction.

Description of the Instruction Decoder

This section describes the instruction decode organization. For processor 500, the instruction decoding accommodates X86 instructions only. The X86 variable-length instructions from the Icache are sent to the fixed-length decode units. Up to six instructions can be decoded and dispatched in one clock cycle. As stated previously, X86 instructions up to four bytes long may be dispatched to a single decode unit, and X86 instructions up to eight bytes long may be dispatched to two successive decode units. All the decode units are similar except for the first and the last decode units. The first and last decode units differ from the others to accommodate instructions which start in one cache line and continue into the next cache line. An important aspect of the decoding is to calculate the operand linear and register addresses. These addresses are used to access the stack relative cache, the X86 registers, and the LOROB. The stack cache and LOROB must check for dependencies. The calculation of the operand addresses is done in the second ICLK of the pipeline. Decoding of the instructions for the functional units can be done in two cycles. Another function of the decode units is to detect RETURN and the unconditional jump instructions, and to break up the line in case of SIB-byte instructions. The global controls of the decode units include a mechanism to stall the line due to limitations of the load/store buffers, the LOROB, and the reservation stations. The decode units should check for the proper end-byte of the instruction and return the instruction to pre-decode if necessary. The MROM interface includes decoding of MROM entry point, latching, and dispatching the various fields of the instruction.

There are three types of instructions that are sent from the Icache: 1) fast path instructions, 2) two-cycle fast path instructions, and 3) MROM instructions. The fast path instructions have at most one prefix: either 0x66 or 0x0F. The two-cycle fast path instructions have at most three prefixes: either 0x66, 0x67, or 0.times.0F. All other prefixes will trap to MROM execution. As mentioned earlier, if a "two-cycle" fast path instruction is detected during pre-decoding, the instruction line will be delayed into the next cycle starting with the two-cycle fast path instruction. The extra cycle is needed to combine the prefixes into one and shift the other bytes of the instruction.

Since each decode unit has only four bytes of instructions and the instructions be up to eight bytes in length, the displacement or immediate field of the instruction may be dispatched to the next decode unit. Each decode unit has a by-pass path for the instruction to go directly to the displacement or immediate register of the previous decode unit. The current instruction decoding is only valid if there is a start-byte in the first byte of the decode unit. In case of the last decode unit for the line of instructions, the immediate field of the instruction must be forwarded one clock cycle later by the first decode unit of the next line.

Calculation of the linear address can be done speculatively because the pre-decode information can give an indication of the location of the displacement. Processor 500 calculates the displacement linear address quickly. The register and linear address operands should be detected and subjected to dependency checking by the stack cache and LOROB in the third cycle of the ICLK signal. The addition of the displacement and contents of the EBP register may be done when the instruction arrives at the decode unit. The first bit sets in byte 3-8 cause the displacement to be added to the contents of the EBP register. The displacement's size depends on the number of bits set. The 32-bit adder without carry-in takes less than 2.4 ns. The speculative linear address should be available by the end of second ICLK.

Other functions of the decode units during the second ICLK are:

Decode the RETURN and unconditional jump instruction to generate taken branch address for the next fetch PC.

Detect the MROM instruction to send byte position to MROM interface unit.

Detect the SIB-byte instruction

Detect the predicted taken branch instruction.

Validate the instruction using start-byte and end-byte.

The opcode decoding of the instructions is not critical and can be done in the next two clock cycles to send to the functional units in the fourth ICLK.

Table 14. Signal list.

IRESET--Global signal used to reset all decode units. Clear all states.

EXCEPTION--Global signal from the LOROB. Used to indicate that an interrupt or trap is being taken. Effect on Idecode is to clear all instructions in progress.

BRNMISP--Input from the Branch execution of the FU indicates that a branch mis-prediction. The Idecode clears all instructions in progress.

ROBEMPTY--Input from the LOROB indicates the LOROB is empty.

ROBFULL--Input from the LOROB indicates the LOROB is full.

CS32.times.16--Input from the LSSEC indicates the size of the code segment register.

SS32.times.16--Input from the LSSEC indicates the size of the stack segment register.

MVTOSRIAD--Input from SRB, indicates a move to IAD special register, Idecode needs to check its pointer against the pointer driven on IAD.

MVFRSRIAD--Input from SRB, indicates a move from IAD special register, Idecode needs to check its pointer against the pointer driven on IAD.

MVTOARIAD--Input from SRB, indicates a move to IAD special register array, Idecode needs to check its pointer against the pointer driven on IAD.

MVFRARIAD--Input from SRB, indicates a move from IAD special register array, Idecode needs to check its pointer against the pointer driven on IAD.

RSFULL--Input from the functional units indicates the reservation station is full.

MROMDEC(5:0)--Input from MROM indicates the microcodes are being decoded by the decode units.

USExREG(5:0)--Input from MROM indicates the global decode registers for the MODRM, displacement, immediate field, and prefix control signals for the microcode instruction.

ICPC(31:0)--Input from Icache indicates the current line PC to pass along with the.sub.-- instruction to the LOROB.

ICPOSx(3:0)--ICLK7 Input from Icache to decode units indicates the PC's byte position of the instruction.

IBDx(31:0)--ICLK7 Input from Icache to decode units indicates the four-byte of the instruction.

ICxSTART--ICLK7 Input from Icache to Idecode indicates the start-byte for the lines of instructions being fetched.

ICxEND(3:0)--ICLK7 Input from Icache to Idecode indicates the end-byte for the lines of instructions being fetched.

ICxFUNC(3:0)--ICLK7 Input from Icache to Idecode indicates the functional-bit for the lines of instructions being fetched.

ICBRN1--Input from Icache, indicates the branch taken prediction of the first target in the ICNXTBLK for the lines of instructions being fetched.

ICBRN2--Input from Icache, indicates the branch taken prediction of the second target in the ICNXTBLK for the lines of instructions being fetched.

ICBCOL1(3:0)--Input from Icache, indicates the column of the first branch target in the ICNXTBLK for the lines of instructions being fetched.

ICBCOL2(3:0)--Input from Icache, indicates the column of the second branch target in the ICNXTBLK for the lines of instructions being fetched.

BTAG1(3:0)--Input from Icache, indicates the position of the first target branch instruction with respect to the global shift register in case of branch mis-prediction.

BTAG2(3:0)--Input from Icache indicates the position of the second target branch instruction with respect to the global shift register in case of branch mis-prediction.

IBTARGET(31:0)--Input from the Icache to decode unit indicates the predicted taken branch target for the line on instruction in the previous cycle.

DESP(31:0)--Input from the stack cache indicates the current ESP to be stored into the return stack with the CALL instruction or to compare with the ESP field for validating the RETURN instruction

RETPRED--Input from Icache indicates the current prediction of the return instruction of the fetched line. The return instruction must be detected in the current line of instruction or the Icache must be re-fetched from a new line.

RETPC(31:0)--Output to Icache indicates the PC address from the top of the return stack for fast way prediction.

UNJMP(5:0)--Output to stack cache and Icache indicates the unconditional branch instruction needs to calculate target address.

BRET(5:0)--Output to stack cache indicates the RETURN instruction needs to read PC from the ESP. This is for the case of the ESP mis-match.

BTADDR(31:0)--Output to functional units indicates the taken branch targets from either the branch prediction (IBTARGET from Icache) or unconditional branch. The functional units need to compare to the actual branch target.

BRNTKN(5:0)--Output indicates which decode unit has a predicted taken branch. The operand steering uses this signal to latch and send BTADDR(31:0) to the functional unit.

BRNINST(5:0)--Output indicates which decode unit has a global branch prediction. The operand steering uses this signal to latch and send BTAG1(3:0) and BTAG2(3:0) to the functional units.

IDPC(31:0)--Output to LOROB indicates the current line PC.

IDxIMM(2:0)--Output to indicates the immediate size information. 01--byte, 10--half word, 11--word, 00--not use. Bit 2 indicates (0) zero or (1) sign extend.

IDxDAT(1:0)--Output to indicates the data size information. 01--byte, 10--half word, 11--word, 00--not use.

IDxADDR--Output to indicates the address size information. 1-32 bit, 0-16 bit.

IDxLOCK--Output to indicates the lock prefix is set for this instruction for serialization.

DxUSEFL(2:0)

DxWRFL(2:0)--Output to LOROB and stack cache indicates the type of flag uses/writes for this instruction of decode units:

xx1 CF--carry flag,

x1x OF--overflow flag,

1xx SF--sign, ZF--zero, PF--parity, and AF--auxiliary carry

DxUSE1(2:0)--Output to LOROB, register file, and stack cache indicates the type of operand being sent on operand 1 for decode units:

0xx register address.

1xx linear address.

x01 A source operand, no destination

x11 A source operand, also destination

x10 B source operand (always no destination)

x00 not use this operand

DxUSE2(1:0)--Output to LOROB and register file indicates the type of operand being sent on operand 2 (operand 2 is always register address) for decode units:

01 first operand, no destination

11 first operand, with destination

10 second operand (always no destination)

00 not use operand 2

INSDISP(5:0)--Indicates that the instruction in decode unit is valid, if invalid, NOOP is passed to LOROB.

RDxPTR1(31:0)--Indicates the linear addresses or register address for operand 1 of decode units.

RDxPTR2(5:0)--Indicates register address for operand 2 of decode units.

IMDIWx(31:0)--Output indicates the 32-bit displacement or immediate field of the instruction to pass to the functional units.

IMDINx(7:0)--Output indicates the 8-bit displacement or immediate field of the instruction to pass to the functional units.

USEIDW(5:0)--Output indicates the type used in IMDIWx buses.

USEIDN(5:0)--Output indicates the type used in IMDINx buses.

INSLSxB(5:0)--Output from decode units indicates the prefix values. bit 5--data size, bit 4--address size, bit 3--lock, bit 2:0--segment registers.

INVBYTE(3:0)--Output to ICPRED indicates the starting byte position of the confused instruction for pre-decoding.

INVPRED--Output to ICPRED indicates pre-decoding for the confused instruction.

INVPOLD--Output to Icache indicates pre-decoding for the previous line of instruction. The ICFPC should start with the previous line.

IDSIB(5:0)--Output to stack cache indicates which decode unit has the SIB-byte instruction.

REFRESH2--Output indicates current line of instructions will be refreshed and not accept new instructions from Icache.

INSOPxB(11:0)--Output indicates the type of instructions being dispatched, this is the decoded information for the functional units to execute.

MROMPOS(5:0)--Output to MIU indicates the byte position of the MROM instruction for the MIU to decode.

MOPBYTE(7:0)--Output from MIU to MROM indicates the opcode-byte of the MROM instruction to use as the entry point.

MREPEAT(2:0)--Output from MIU to MROM indicates the repeat-byte for string operation of the MROM instruction.

Early Decoding

The early decoding has to be done within the first half of the second ICLK cycle. The decoding includes validating the instruction, calculating the operands and flags, detecting the return and unconditional branch instructions, and generating control signals for EBP and ESP.

Validating The Instruction

The instructions from the Icache may not be valid if the start-byte and end-byte are not properly set. The decode unit needs to use the start-byte and end-byte to validate every byte of the instruction. Each instruction should have a start-byte at the first byte of the decode unit and an end-byte within the next eight bytes. If the end-byte is not detected within the eight-byte boundary for the fast path instruction, the instruction must be sent back to the Icache for pre-decoding. The end-byte must also be detected for the MROM instruction which may have more than eight bytes in the MROM interface unit. For the case of instruction continuing to the next line, the Icache must re-fetch from the previous line for invalid instruction. The IFPC must retain the previous line PC in this case. The conditions necessary to validate the instruction and each byte are shown in FIG. 28.

Calculating Operands and Flags

With up to six instructions possibly dispatched every clock cycle, twelve possible read operands must be checked for data dependency every clock cycle. The LOROB checks all previously dispatched instructions (up to four lines or 24 instructions) for dependencies, and the stack cache checks for dependencies among the six instructions being dispatched. In the LOROB, the number of comparators is 24 by 6 for the 32-bit linear addresses and 24 by 6 for the 6-bit register operands. In the stack cache, the number of comparators is 15 for the 32-bit linear addresses and 15 for the 6-bit register operands. It is important that the decode units calculate the linear addresses and identify the register operands as soon as possible. The 32-bit adds without carry-in can be accomplished in 2.4 ns. Flags are in the same category with the operands which need early indication. Some of the X86 opcode has implied references to registers and flags. The register operands are from MODRM byte. The linear address is calculated by adding the displacement to contents of the EBP register.

FIG. 29 is a block diagram of hardware within processor 500 which is used to calculate linear addresses and identify register operands. The X86 instruction set includes two-operand instructions with at most one memory reference. To increase the efficiency of the LOROB and the stack cache dependency checking operations, the 32-bit linear address should always be on first operand, and the register operand should always be on second operand. The first operand can alternatively have register operand. For naming convention, the suffix 1 and 2 are operands from the decode units to the LOROB, the stack cache, and the register file. The suffix A and B are operands from the LOROB, the stack cache, and the register file to the reservation stations and functional units. The operands A and B should be in the correct instruction's order. The first and second operand have tags to indicate read/write and memory/register references:

The operand steering performed by the LOROB, the stack cache, and the register file use the above tag information to send the operand's data in the correct instruction's order to the functional units. The order of the operands is not known until the actual decoding of the instruction opcode. The benefits of switching the order of operands include:

(1) A cycle gain in performance. Decode units only need to decode the MODRM byte to send the operands, the order of the operand is only known from decoding the opcode which is complex. The order of the operand is not needed until dispatching of instructions to functional units.

(2) Simplify the access to the LOROB and stack cache. The 32-bit linear address is always on the first operand instead of either operands, the dependency checking in the LOROB and the stack cache is simpler. The LOROB dependency checking for each dispatched instruction requires one 32-bit comparator for linear address or register, and one 6-bit comparator for register. Only the first operand accesses the stack cache.

(3) Flexibility of switching the operands to simplify the operation of the functional units. For the Subtract Reverse Instruction, the instruction will be dispatched to the functional unit as a Subtract Instruction with the A and operand 2 reverse.

The MODRM byte has 3 fields: REG, MOD, and R/M. The REG field is sent as the second operand. The linear address is calculated and validated the first operand for two cases:

MOD=01 and R/M=011, 8-bit displacement

MOD=10 and R/M=011, 32 or 16-bit displacement

Bit 2 of the operand tag is set for the linear address. Otherwise, the R/M field is sent as the first operand (register).

FIG. 30 is a block diagram showing how operands are identified and provided to the reservation stations and functional units.

Fast Decoding for Operands and Flags

The condition for validating the displacement linear address is based on the MODRM. The MODRM byte has to be present with 01xxx101 and there should not be any SIB byte. The first byte after the opcode byte is MODRM and the second byte after the opcode byte is the displacement byte. With the pre-decode information, the MODRM byte is known with certainty, the register addresses can also be calculated quickly. The instructions with implied register in the opcode should also be decoded:

The decoding of the status flags also needs to be accomplished during ICLK2. The status flags are set up in three groups: CF--carry flag, OF--overflow flag, and the rest of the ALU flags, XF (SF--sign flag, ZF--zero flag, PF--parity flag, and AF--auxiliary carry flag). The instructions must provide the reading and writing of the status flags in the same manner as the operands. The decoding of the status flags is as followed:

Table 17. Signal list.

IBD0(31:0)--ICLK7 Input from Icache to decode unit 0 indicates the 4-byte of the instruction.

IBD1(31:0)--ICLK7 Input from Icache to decode unit 1 indicates the 4-byte of the instruction.

IBD2(31:0)--ICLK7 Input from Icache to decode unit 2 indicates the 4-byte of the instruction.

IBD3(31:0)--ICLK7 Input from Icache to decode unit 3 indicates the 4-byte of the instruction.

IBD4(31:0)--ICLK7 Input from Icache to decode unit 4 indicates the 4-byte of the instruction.

IBD5(31:0)--ICLK7 Input from Icache to decode unit 5 indicates the 4-byte of the instruction.

ICxSTART--ICLK7 Input from Icache to Idecode indicates the start-byte for the lines of instructions being fetched.

ICxEND(3:0)--ICLK7 Input from Icache to Idecode indicates the end-byte for the lines of instructions being fetched.

ICxFUNC(3:0)--ICLK7 Input from Icache to Idecode indicates the functional-bit for the lines of instructions being fetched.

D0USEFL(2:0)

D0WRFL(2:0)--Output to LOROB and stack cache indicates the type of flag uses/writes for this instruction of decode unit 0:

xx1 CF--carry flag,

x1x OF--overflow flag,

1xx SF--sign, ZF--zero, PF--parity, and AF--auxiliary carry

D1USEFL(2:0)

D1WRFL(2:0)--Output to LOROB and stack cache indicates the type of flag uses/writes for this instruction of decode unit 1.

D2USEFL(2:0)

D2WRFL(2:0)--Output to LOROB and stack cache indicates the type of flag uses/writes for this instruction of decode unit 2.

D3USEFL(2:0)

D3WRFL(2:0)--Output to LOROB and stack cache indicates the type of flag uses/writes for this instruction of decode unit 3.

D4USEFL(2:0)

D4WRFL(2:0)--Output to LOROB and stack cache indicates the type of flag uses/writes for this instruction of decode unit 4.

D5USEFL(2:0)

D5WRFL(2:0)--Output to LOROB and stack cache indicates the type of flag uses/writes for this instruction of decode unit 5.

D0USE1(2:0)--Output to LOROB, register file, and stack cache indicates the type of operand being sent on operand 1 for decode unit 0:

0xx register address.

1xx linear address.

x01 A source operand, no destination

x11 A source operand, also destination

x10 B source operand (always no destination)

x00 not use this operand

D1USE1(2:0)--Output to LOROB, register file, and stack cache indicates the type of operand being sent on operand 1 for decode unit 1.

D2USE1(2:0)--Output to LOROB, register file, and stack cache indicates the type of operand being sent on operand 1 for decode unit 2.

D3USE1(2:0)--Output to LOROB, register file, and stack cache indicates the type of operand being sent on operand 1 for decode unit 3.

D4USE1(2:0)--Output to LOROB, register file, and stack cache indicates the type of operand being sent on operand 1 for decode unit 4.

D5USE1(2:0)--Output to LOROB, register file, and stack cache indicates the type of operand being sent on operand 1 for decode unit 5.

D0USE2(1:0)--Output to LOROB and register file indicates the type of operand being sent on operand 2 (operand 2 is always register address) for decode unit 0:

01 first operand, no destination

11 first operand, with destination

10 second operand (always no destination)

00 not use operand 2

D1USE2(1:0)--Output to LOROB and register file indicates the type of operand being sent on operand 2 (operand 2 is always register address) for decode unit 1.

D2USE2(1:0)--Output to LOROB and register file indicates the type of operand being sent on operand 2 (operand 2 is always register address) for decode unit 2.

D3USE2(1:0)--Output to LOROB and register file indicates the type of operand being sent on operand 2 (operand 2 is always register address) for decode unit 3.

D4USE2(1:0)--Output to LOROB and register file indicates the type of operand being sent on operand 2 (operand 2 is always register address) for decode unit 4.

D5USE2(1:0)--Output to LOROB and register file indicates the type of operand being sent on operand 2 (operand 2 is always register address) for decode unit 5.

INSDISP(5:0)--Indicates that the instruction in decode unit is valid, if invalid, NOOP is passed to LOROB.

RD0PTR1(31:0)--Indicates the linear addresses or register address for operand 1 of decode unit 0.

RD1PTR1(31:0)--Indicates the linear addresses or register address for operand 1 of decode unit 1.

RD2PTR1(31:0)--Indicates the linear addresses or register address for operand 1 of decode unit 2.

RD3PTR1(31:0)--Indicates the linear addresses or register address for operand 1 of decode unit 3.

RD4PTR1(31:0)--Indicates the linear addresses or register address for operand 1 of decode unit 4.

RD5PTR1(31:0)--Indicates the linear addresses or register address for operand 1 of decode unit 5.

RD0PTR2(31:0)--Indicates register address for operand 2 of decode unit 0.

RD1PTR2(31:0)--Indicates register address for operand 2 of decode unit 1.

RD2PTR2(31:0)--Indicates register address for operand 2 of decode unit 2.

RD3PTR2(31:0)--Indicates register address for operand 2 of decode unit 3.

RD4PTR2(31:0)--Indicates register address for operand 2 of decode unit 4.

RD5PTR2(31:0)--Indicates register address for operand 2 of decode unit 5.

IMDIW0(31:0)

IMDIW1(31:0)

IMDIW2(31:0)

IMDIW3(31:0)

IMDIW4(31:0)

IMDIW5(31:0)--Output indicates the 32-bit displacement or immediate field of the instruction to pass to the functional units.

IMDIN0(7:0)

IMDIN1(7:0)

IMDIN2(7:0)

IMDIN3(7:0)

IMDIN4(7:0)

IMDIN5(7:0)--Output indicates the 8-bit displacement or immediate field of the instruction to pass to the functional units.

USEIDW(5:0)--Output indicates the type used in IMDIWX buses.