Patent Description:
Processors are a critical component of many digital systems, often determining how much performance and/or power efficiency can be achieved in the system. In some cases, a subset of the instruction set implemented by the processors can be implemented in a coprocessor that can be higher performance and/or more efficient at executing the instructions than the processor. Alternatively, instructions can be added to the instruction set that are specifically designed to be executed by the coprocessor, using specialized hardware that a general purpose processor would not implement.

Once a coprocessor is added to the system, it can be challenging to efficiently transport instructions to the coprocessor. Not only does the processor need to transmit the instructions to the coprocessor in an efficient manner, but also the processor needs to provide enough instructions to the coprocessor to keep the coprocessor busy in cases where the code being executed includes significant numbers of coprocessor instructions. <CIT> discloses a method involving storing wide command data in a first physical structure of a processor. The information associated with the wide command is determined based on the data or a corresponding memory address range associated with the first physical structure of processor. The information determined includes a size of the command and is stored in a second physical structure of processor. The first/second physical structures are caused to provide the wide command data and information associated with the command directly to a coprocessor for executing the command. Having storage capacity enough to store data associated with multiple commands in a scratchpad allows multiple transactions, between the core processor and the coprocessor, to be outstanding simultaneously. <CIT> discloses a processor with a hybrid instruction queue with instruction elaboration between sections. <CIT> relates to combining a write buffer with dynamically adjustable flush metrics. <CIT> discloses a reconfigurable, application-specific computer accelerator.

In an embodiment, a processor includes a buffer in an interface unit configured to store cache lines of data to be transmitted from the processor to other components in a system including the processor (e.g. to a second level cache or other level of cache in the system, or the memory). The buffer may also be used to accumulate coprocessor instructions to be transmitted to a coprocessor. In an embodiment, the processor issues the coprocessor instructions to the buffer when ready to be issued to the coprocessor. The interface unit may accumulate the coprocessor instructions in the buffer, generating a bundle of instructions. The bundle/buffer entry may be closed based on various predetermined conditions (e.g. bundle complete, timer expiration, or detection of certain other instructions), and then the bundle may be transmitted to the coprocessor. According to the invention, the issuance of instructions to the buffer, the closure of the bundle/buffer, and the transmission of the bundle to the coprocessor is designed to ensure that, if a sequence of coprocessor instructions appears consecutively in a program, the rate at which the instructions are provided to the coprocessor (on average) at least matches the rate at which the coprocessor consumes the instructions.

The following detailed description makes reference to the accompanying drawings, which are now briefly described.

While embodiments described in this disclosure may be 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 embodiments to the particular form disclosed. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description. As used throughout this application, the word "may" is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words "include", "including", and "includes" mean "including, but not limited to. " As used herein, the terms "first," "second," etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless specifically stated.

Within this disclosure, different entities (which may variously be referred to as "units," "circuits," other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. This formulation-[entity] configured to [perform one or more tasks]-is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be "configured to" perform some task even if the structure is not currently being operated. A "clock circuit configured to generate an output clock signal" is intended to cover, for example, a circuit that performs this function during operation, even if the circuit in question is not currently being used (e.g., power is not connected to it). Thus, an entity described or recited as "configured to" perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. The hardware circuits may include any combination of combinatorial logic circuitry, clocked storage devices such as flops, registers, latches, etc., finite state machines, memory such as static random access memory or embedded dynamic random access memory, custom designed circuitry, analog circuitry, programmable logic arrays, etc. Similarly, various units/circuits/components may be described as performing a task or tasks, for convenience in the description.

The term "configured to" is not intended to mean "configurable to. " An unprogrammed FPGA, for example, would not be considered to be "configured to" perform some specific function, although it may be "configurable to" perform that function. After appropriate programming, the FPGA may then be configured to perform that function.

In an embodiment, hardware circuits in accordance with this disclosure may be implemented by coding the description of the circuit in a hardware description language (HDL) such as Verilog or VHDL. The HDL description may be synthesized against a library of cells designed for a given integrated circuit fabrication technology, and may be modified for timing, power, and other reasons to result in a final design database that may be transmitted to a foundry to generate masks and ultimately produce the integrated circuit. Some hardware circuits or portions thereof may also be custom-designed in a schematic editor and captured into the integrated circuit design along with synthesized circuitry. The integrated circuits may include transistors and may further include other circuit elements (e.g. passive elements such as capacitors, resistors, inductors, etc.) and interconnect between the transistors and circuit elements. Some embodiments may implement multiple integrated circuits coupled together to implement the hardware circuits, and/or discrete elements may be used in some embodiments. Alternatively, the HDL design may be synthesized to a programmable logic array such as a field programmable gate array (FPGA) and may be implemented in the FPGA.

As used herein, the term "based on" or "dependent on" is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect the determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase "determine A based on B. " This phrase specifies that B is a factor used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on.

This specification includes references to various embodiments, to indicate that the present disclosure is not intended to refer to one particular implementation.

This specification may use the words "a" or "an" to refer to an element, or "the" to refer to the element. These words are not intended to mean that there is only one instance of the element. There may be more than one in various embodiments. Thus, "a", "an", and "the" should be interpreted to mean "one or more" unless expressly described as only one.

This specification may describe various components, units, circuits, etc. as being coupled. In some embodiments, the components, units, circuits, etc. may be coupled if they are electrically coupled (e.g. directly connected or indirectly connected through one or more other circuits) and/or communicatively coupled.

Turning now to <FIG>, a block diagram of one embodiment of an apparatus including a CPU processor <NUM>, a coprocessor <NUM>, and a level two (L2) cache <NUM> is shown. In the illustrated embodiment, the CPU processor <NUM> is coupled to the L2 cache <NUM> and the coprocessor <NUM>. In some embodiments, the coprocessor <NUM> may be coupled to the L2 cache <NUM> as well. The CPU processor <NUM> may further include an instruction cache (ICache) <NUM>, a data cache (DCache) <NUM>, and one or more pipeline stages (illustrated as the ellipses in <FIG>, along with the coprocessor issue circuit <NUM> and the core interface unit (CIF) <NUM>, each of which may implement one or more pipeline stages of the pipeline). The coprocessor issue circuit <NUM> is coupled to the pipeline to receive coprocessor instructions, and includes an instruction queue <NUM> to store the coprocessor instructions. The coprocessor issue circuit <NUM> is coupled to the CIF <NUM>, which is further coupled to the L2 cache <NUM>, the DCache <NUM>, and optionally to the coprocessor <NUM>. In some embodiments, circuits may be coupled if they are electrically coupled (e.g. directly connected or indirectly connected through one or more other circuits) and/or communicatively coupled.

The coprocessor <NUM> may be configured to perform one or more computation operations and one or more coprocessor load/store operations. The coprocessor <NUM> may employ an instruction set, which may be a subset of the instruction set implemented by the CPU processor <NUM>. The CPU processor <NUM> may recognize instructions implemented by the coprocessor <NUM> and may communicate the instructions to the coprocessor <NUM>.

More particularly, the CPU processor <NUM> may provide the coprocessor instructions to the coprocessor issue circuit <NUM>, which may queue the coprocessor instructions in the instruction queue <NUM>. The coprocessor issue circuit <NUM> is configured to issue the coprocessor instructions to the CIF <NUM> for transmission to the coprocessor <NUM>, using one or more "coprocessor issued" paths shown in <FIG> (e.g. path <NUM> and optional parallel path <NUM>). The paths may be pipelines of one or more stages to transmit the coprocessor instructions to the CIF <NUM>. In an embodiment, when more than one path/pipeline is provided, the paths/pipelines may be independent and may thus permit more than one coprocessor instruction to be issued in parallel to the CIF <NUM>.

The CIF <NUM> includes an address buffer <NUM> and a data buffer <NUM> in the illustrated embodiment. The address buffer <NUM> may include multiple entries, and the data buffer <NUM> may include multiple entries as well. Each entry of the address buffer <NUM> may correspond to a respective entry of the data buffer <NUM>. In an embodiment, the data buffer entries may each be configured to store a cache line of data from the DCache <NUM>. The cache line of data may have been evicted from the DCache <NUM> and may be stored in the CIF <NUM> for transmission to the L2 cache <NUM> for storage. The corresponding address buffer entry may store the address of the cache line, as well as other data related to the cache line including data identifying the entry as being a cache line eviction. Thus, CIF <NUM> may be normally designed to transmit one operation on the interface to the L2 cache <NUM> (one cache block). In addition to cache block evictions, the CIF <NUM> may also enqueue various cache maintenance operations (e.g. cache flushes) at one operation per entry, cache fill requests for the DCache <NUM> and ICache <NUM> at one operation per entry, etc..

When coprocessor instructions are being issued, the data buffer <NUM> may accumulate coprocessor instructions in a bundle to be transmitted to the coprocessor <NUM>. The corresponding address buffer entry may store data indicating that the entry is accumulating coprocessor instructions, but there may not be an explicit address for the address buffer entry to store. The coprocessor issue circuit <NUM> transmits data corresponding to one or more issued coprocessor instructions, and the CIF <NUM> allocates a data buffer entry to accumulate the instructions. Additional coprocessor instructions may subsequently be issued by the coprocessor issue circuit <NUM>. The CIF <NUM> may merge the additional coprocessor instructions into the bundle.

Various conditions may cause the coprocessor issue circuit <NUM> to close the bundle (described in more detail below). According to the invention, a command is associated with the bundle, and is written to the data buffer <NUM> when the bundle is closed (that is, the command may be part of the bundle). Alternatively, the command may be written to the address buffer <NUM> or another storage location, in other embodiments. The command may be accumulated by the coprocessor issue circuit <NUM>, or may be accumulated by the CIF <NUM>, in various embodiments. The command accumulation is this illustrated in dotted form (CMD <NUM>) in the coprocessor issue circuit <NUM>/CIF <NUM>. The CMD <NUM> may be, e.g., a storage device such as a register, a set of flip flops (flops), etc. to store the accumulated command information. The combination of the command and the data transmitted for each coprocessor instruction may identify the coprocessor instructions to the coprocessor <NUM>. Additional details will be provided below.

This description may refer to having an open bundle and closing the bundle (at which time additional coprocessor instructions may not be added to the bundle and the bundle is ready to transmit to the coprocessor <NUM>). This description may also refer to an open buffer entry in the CIF <NUM>, and closing the buffer entry. The two descriptions may be essentially synonymous: a bundle may be open if the buffer entry storing the bundle is open, and the bundle may be closed if the buffer entry is closed and is arbitrating with other buffer entries to transmit on the CIF interface to the coprocessor <NUM>.

The coprocessor issue circuit <NUM> and the CIF <NUM> attempt to transmit coprocessor instructions to the coprocessor <NUM> at a rate that matches the rate that the coprocessor <NUM> may consume instructions. That is, if a code sequence includes numerous coprocessor instructions in series, the coprocessor issue circuit <NUM> and the CIF <NUM> attempt to provide instructions to the coprocessor <NUM> to permit the coprocessor <NUM> to consume instructions at its maximum rate. For example, in one embodiment, the coprocessor <NUM> may be configured to consume up to two coprocessor instructions per clock cycle. The coprocessor issue circuit <NUM> may attempt to issue two coprocessor instructions per clock cycle whenever instructions are available and issuable. The CIF <NUM> may accumulate the instructions, then transmit the bundle to the coprocessor <NUM>. If a series of coprocessor instructions are encountered in a code sequence, the bundle may be generated at a rate of two instructions per clock cycle and may be transmitted as one bundle, providing an average of two instructions per clock cycle to the coprocessor <NUM>. In another embodiment, the coprocessor <NUM> may be configured to consume up to three instructions per clock cycle. The coprocessor issue circuit <NUM> and the CIF <NUM> may attempt to bundle instructions at a three instruction per clock cycle rate, and transmit the bundles to the coprocessor <NUM> to support an average of three instructions per clock. Any rate may be implemented in various embodiments. The rates of two and three instructions per clock are merely examples for this disclosure.

In one embodiment, the CIF <NUM> may transmit the bundle directly to the coprocessor <NUM> (e.g. the coprocessor <NUM> may be coupled to the interface between the L2 cache <NUM> and the CPU processor <NUM>, or there may be a separate interface between the CPU processor <NUM> and the coprocessor <NUM> and the CIF <NUM> may transmit the bundle on the separate interface). In another embodiment, the CPU processor <NUM> may transmit the bundle to the L2 cache <NUM>, in a manner similar to evicted cache lines or cache maintenance operations. The L2 cache <NUM> may detect the bundle of coprocessor instructions and route the bundle to the coprocessor <NUM>. These options are illustrated in <FIG> by the dotted lines between the CPU processor <NUM> and the coprocessor <NUM>, and between the L2 cache <NUM> and the coprocessor <NUM>.

The interface to the L2 cache <NUM> may include an address bus, a data bus, and byte enables. For communications to the L2 cache <NUM> itself (e.g. cache evictions, cache maintenance operations, etc.), the address bus may carry information identifying the operation being performed, as well as the affected address. The data bus may carry the cache line, if the CPU processor <NUM> has cache data to transmit for the operation. The byte enables may identify which bytes of the data bus are valid. When transmitting a coprocessor instruction bundle, the CPU processor <NUM> may transmit the bundle on the data bus, and the address bus may include information identifying the transmission as bundle of coprocessor instructions. In another embodiment, since there is no address associated with the bundle, the address may be used to transmit some of the bundle. For example, the command may be transmitted on the address bus, and the remaining bundle data may be transmitted on the data bus. In yet another embodiment, the command may include a valid indication identifying a number of coprocessor instructions in the bundle, and thus the byte enables need not be used for transmitting bundles. The byte enables may be used to transmit the command in such embodiments. For embodiments in which the command is transmitted on the byte enables or address bus, additional coprocessor instructions may be included in a bundle in the space that would have been occupied by the command.

Based on the address bus information identifying the transmission as a coprocessor instruction bundle, the L2 cache <NUM> may be configured to route the bundle to the coprocessor <NUM>. The coprocessor <NUM> may receive the bundle (e.g. in an instruction buffer, shown in <FIG> and discussed below) and may consume the instructions from the bundle.

As mentioned above, various conditions may cause the bundle to be closed. In one embodiment, a timer <NUM> may be used as one condition to close the buffer. The timer <NUM> may be initialized when the bundle is started with an initial one or more coprocessor instructions, and may be updated each clock cycle. When the timer <NUM> expires, the bundle may be closed. The timer <NUM> may be initialized to a desired number of clock cycles and decremented, expiring when it reaches zero. Alternatively, the timer <NUM> may be initialized to zero and incremented, expiring when it reached the desired number of clock cycles. The desired number of clock cycles may be fixed or programmable, in various embodiments. While the timer <NUM> is implemented in the coprocessor issue circuit <NUM> in the illustrated embodiment, other embodiments may implement the timer <NUM> in the CIF <NUM>.

In an embodiment, operations may be issued from the instruction queue <NUM> when they are no longer speculative. Generally, an instruction or operation may be non-speculative if it is known that the instruction is going to complete execution without exception/interrupt. Thus, an instruction may be non-speculative once prior instructions (in program order) have been processed to the point that the prior instructions are known to not cause exceptions/speculative flushes in the CPU processor <NUM> and the instruction itself is also known not to cause an exception/speculative flush. Some instructions may be known not to cause exceptions based on the instruction set architecture implemented by the CPU processor <NUM> and may also not cause speculative flushes. Once the other prior instructions have been determined to be exception-free and flush-free, such instructions are also exception-free and flush-free.

The CPU processor <NUM> may be responsible for fetching the instructions executed by the CPU processor <NUM> and the coprocessor <NUM>, in an embodiment. The CPU processor <NUM> may be configured to decode instructions into operations. In some embodiments, there may be a one-to-one correspondence between instructions and operations (e.g. a given instruction may decode into one operation). In such cases, instruction and operation may be effectively synonymous, although the operation may be modified in form by the decoder or other circuitry in the CPU processor <NUM>. In other embodiments, at least some instructions may be decoded into multiple operations. The multiple operations, when executed, may implement the operation specified for the corresponding instructions. Combinations of instructions which decode one-to-one and instructions which decode one-to-multiple may be supported in an embodiment. Some instructions may be microcoded as well, in an embodiment. Thus, load/store operations may be instructions, or may be one of the operations decoded from a given instruction.

In an embodiment, the CPU processor <NUM> may be configured to detect consecutive coprocessor instructions in a code sequence and fuse the consecutive coprocessor instructions into a fused instruction. The instructions may be consecutive in the code sequence if they are adjacent in program order (e.g. no other instruction intervenes between the adjacent coprocessor instructions in program order). The fused instruction progresses as a single instruction down the pipeline of the CPU processor <NUM> and is written to the instruction queue <NUM> as a single instruction. Instruction fusion may be used to increase the rate at which instructions are bundled and issued to the CIF <NUM> using one coprocessor issue path <NUM> or <NUM>, but occupying two slots in the bundle for the two instructions.

While the communication path between the CPU processor <NUM> and the L2 cache <NUM>/coprocessor <NUM> is described above as an address bus and data bus, any type of communication may be used in various embodiments. For example, a packet-based communication system could be used to transmit memory requests to the L2 cache <NUM> and/or system memory and instructions to the coprocessor <NUM>.

A cache line may be the unit of allocation/deallocation in a cache. That is, the data within the cache line may be allocated/deallocated in the cache as a unit. Cache lines may vary in size (e.g. <NUM> bytes, <NUM> bytes, <NUM> bytes, or larger or smaller cache lines). Different caches may have different cache line sizes. For example, the DCache <NUM> may have a smaller cache line size than the L2 cache <NUM>, in an embodiment. The instruction cache <NUM> and DCache <NUM> may each be a cache having any desired capacity, cache line size, and configuration. Similarly, the L2 cache <NUM> may be any capacity, cache line size, and configuration. The L2 cache <NUM> may be any level in the cache hierarchy (e.g. the last level cache (LLC) for the CPU processor <NUM>, or any intermediate cache level between the CPU processor <NUM>/coprocessor <NUM> and the main memory system). There may be more levels of cache between the CPU DCache <NUM>/ICache <NUM> and the L2 cache <NUM>, and/or there may be additional levels of cache between the L2 cache <NUM> and the main memory.

The above discussion has described the coprocessor issue circuit <NUM> and the CIF <NUM> being configured to perform various operations in this discussion. Each of coprocessor issue circuit <NUM> and the CIF <NUM> may include control logic circuitry (e.g. illustrated as control logic 20A and 34A, respectively in <FIG>) implementing the operations.

Turning now to <FIG>, a block diagram illustrating one embodiment of a CIF data buffer entry <NUM> when it is accumulating/storing a bundle of coprocessor instructions is shown. The data buffer entry <NUM> may be a cache line in size, as previously mentioned. In one embodiment, the cache line may be <NUM> bytes. Additionally, the data describing each coprocessor instruction (in addition to the opcode included in the command, in an embodiment) may be <NUM> bits (<NUM> bytes). The command may also be <NUM> bits (<NUM> bytes) in an embodiment. Other embodiments may employ different cache line sizes and instruction data/command sizes.

In the embodiment shown in <FIG>, the data buffer entry <NUM> is divided into slots for the command (reference numeral <NUM>) and one or more instruction payloads (reference numerals 44A-<NUM>). The instruction payloads may be the instruction data issued by the coprocessor issue circuit <NUM> for each instruction. In one embodiment, the instruction payload may be the entirety of the instruction. In the embodiment shown, however, the opcode for each instruction is included in the command <NUM> as discussed below. A given instruction payload 44A-<NUM> and the corresponding opcode, when taken together, describe the instruction to the coprocessor <NUM>. That is, a given instruction is defined by its opcode and payload. By decoding the opcode and payload, the coprocessor <NUM> may determine the instruction to be executed, the location of operations of the instruction in the coprocessor, etc..

The instruction payload 44E is shown in exploded view in <FIG> for two types of coprocessor instructions: load/store instructions and other instructions (e.g. computation instructions). The payload for load/store instructions is illustrated at reference numeral <NUM>, and the payload for computation instructions is illustrated at reference numeral <NUM>. Each instruction payload 44A-<NUM> may be similar to the instruction payload 44E as shown in the exploded view, depending on whether the instruction is a load/store or compute instruction.

According to the invention, the coprocessor computation instructions are defined to have an opcode and a CPU processor register as a source operand when fetched by the CPU processor <NUM>. The CPU processor register may be an integer register, and more particularly may be a <NUM> bit integer register in this embodiment. The contents of the CPU processor register, along with the opcode, may define the instruction to the coprocessor <NUM>. For example, the contents of the CPU processor register may specify operands within the coprocessor <NUM>, and may further specify the instruction (e.g. the opcode detected by the CPU processor <NUM> may define a group of instructions and the contents of the CPU processor register may select one of the instructions from the group). Thus, the instruction as transmitted to the coprocessor <NUM> are the opcode (in the command, in this embodiment) and the contents of the source register as the payload <NUM>.

For load/store instructions, the CPU processor <NUM> may be responsible for translating the address of the memory location read/written in response to the load/store instruction. Thus, the payload <NUM> includes a PA field for the physical address of the load/store operation. There may also be a completion ID (CompID) field which identifies the coprocessor load/store operation to the CPU processor <NUM> when it is completed, for ordering purposes with CPU load/store operations. One or more cache attributes (CA) may be included, which may be determined from the address translation and/or other sources in various embodiments. Cache attributes may include one or more of a cacheable/uncacheable attribute, a write through attribute, a coherent/non-coherent attribute, etc. Cache attributes may affect the behavior of caches in the memory hierarchy with respect to the data accessed by the load/store instruction. For example, the caches may determine whether or not to cache the data, how to handle writes to the data, etc. based on the cache attributes. The payload <NUM> may further specify the target (load) or source (store) register within the coprocessor <NUM> for the load/store data (CopReg), and in some embodiments may further include one or more hints regarding the use of the data (e.g. temporal vs. non-temporal, etc.) which may be used by the L2 cache <NUM> for caching the data in addition to the cache attributes.

As shown in <FIG>, the bundle may have up to <NUM> instructions (corresponding to the <NUM> payloads 44A-<NUM> shown in <FIG>). Embodiments in which the command is transmitted on the address bus or byte enables may include a payload in the place of the command <NUM>. However, not all embodiments may support a full <NUM> instruction payload. For example, payload <NUM> is shown in dotted form in <FIG> to illustrate the payload <NUM> may not be used in some embodiments. Similarly, the corresponding opcode field in the command is shown in dotted form. An embodiment in which the coprocessor <NUM> consumes up two instructions per cycle may not include the payload <NUM>. Since the first six payloads may be provided at two instructions per cycle (in the case of a stream of consecutive coprocessor instructions), a two instruction per clock average may be maintained if the bundles have an even number of coprocessor instructions. Accordingly, for such an embodiment, a bundle may be defined to be complete when the bundle has <NUM> instructions. The space where payload <NUM> would be located in the data buffer may be reserved (not used).

On the other hand, an embodiment in which the coprocessor consumes up to three instructions per clock cycle may benefit from including the payload <NUM>, depending on how the instructions fill the bundle. Additional details are for an example of such an embodiment are described below with regard to <FIG>.

The command <NUM> is shown in exploded view in <FIG> as well, for an embodiment. The command <NUM> includes opcode fields for each opcode in the bundle (reference numerals 52A-<NUM> corresponding to payloads 44A-<NUM>, respectively, in this embodiment). As mentioned previously, the opcode <NUM> may not be included in some embodiments, and the corresponding field on the command may be reserved in such an embodiment. The command <NUM> may also include a context ID field <NUM>, which may identify a processor context that sourced the coprocessor instructions. The command <NUM> may include a valid indication <NUM> to identify which instructions in the bundle are valid. For example, the valid indication may be a mask with a bit for each coprocessor instruction, which may be set to indicate the instruction is valid (e.g. present in the bundle) and clear to indicate that the instruction in invalid (e.g. not present in the bundle). The opposite meanings for the set and clear states of the bit may also be used if desired. Other embodiments may use other valid indications. For example, the instructions in the bundle may be provided in order from payload o to payload <NUM>. Accordingly, a count of instructions may be used as the valid indication, for example.

Turning next to <FIG>, a flowchart is shown illustrating operation of the coprocessor issue circuit <NUM> to issue a coprocessor instruction that is at the head of the instruction queue <NUM>. Similar operation may be performed in parallel to identify additional issuable coprocessor instructions, for embodiments that transmit multiple instruction operations in parallel to the CIF <NUM>. While the blocks are shown in a particular order for ease of understanding, other orders may be used. Blocks, combinations of blocks, and/or the flowchart as a whole may be pipelined over multiple clock cycles. The coprocessor issue circuit <NUM>, or components thereof, may be configured to implement the operation illustrated in <FIG>.

As mentioned previously, the coprocessor issue circuit <NUM> may wait for the coprocessor instruction to become non-speculative prior to issuing the instruction (decision block <NUM>). Once the coprocessor instruction is non-speculative (decision block <NUM>, "yes" leg), the coprocessor issue circuit <NUM> may determine if there is an open bundle (decision block <NUM>). There may be an open bundle if one or more previous coprocessor instructions have been issued to the bundle, but the bundle is not yet complete or closed for another reason. If there is an open bundle (decision block <NUM>, "yes" leg), the coprocessor issue circuit <NUM> may update the command to indicate the coprocessor instruction (e.g. writing the opcode to the next open opcode field 52A-<NUM> and updating the valid mask <NUM>) (block <NUM>). The coprocessor issue circuit <NUM> may determine the offset into the data buffer <NUM> at which the instruction payload is to be written to merge the data into the data buffer <NUM> (block <NUM>). For example, in the embodiment of <FIG>, the offset for payload o may be <NUM> bytes (since the command is <NUM> bytes beginning at offset o), the offset for payload <NUM> may be <NUM> bytes, etc. Other embodiments may have different offsets depending on the bundle definition and the size of the payloads and command. The instructions may be filled into the bundle in program order, so the first instruction in the bundle may be offset at <NUM> bytes, then second instruction offset at <NUM> bytes, etc. The coprocessor issue circuit <NUM> may transmit the payload and offset to the CIF <NUM> to update the bundle in the data buffer <NUM> (block <NUM>). In embodiments in which the CIF <NUM> generates the command, block <NUM> may be performed in the CIF <NUM> in response to receiving the payload and offset. Additionally, the opcode may be transmitted to the CIF <NUM> with the payload for embodiments in which the CIF <NUM> accumulates the command.

If the transmission of the coprocessor instruction completes the bundle (decision block <NUM>, "yes" leg), the coprocessor issue circuit <NUM> may also transmit the command to the CIF <NUM> (for embodiments in which the coprocessor issue circuit <NUM> generates the command) (block <NUM>). The command may be transmitted in parallel with the payload (e.g. in an unused pipeline or path <NUM>/<NUM>), or subsequent to the payload, in various embodiments. The command may be transmitted with offset o, and the update at offset o may signal to the CIF <NUM> that the bundle is complete, in an embodiment. Alternatively, signaling between the coprocessor issue circuit <NUM> and the CIF <NUM> may identify the command transmission or payload transmission. For embodiments in which the command is generated in the CIF <NUM>, the coprocessor issue circuit <NUM> may signal the CIF <NUM> that the bundle is complete (or for other bundle closure reasons, described in more detail below).

If there is no open bundle (decision block <NUM>, "no" leg), the coprocessor issue circuit <NUM> may be configured to initialize the command (block <NUM>) and may also be configured to initialize the timer <NUM> (block <NUM>). The buffer offset in this case may be the offset to payload o (block <NUM>). The coprocessor issue circuit <NUM> may transmit the payload and offset to the CIF <NUM> (block <NUM>). The bundle may not be complete in this case (decision block <NUM>, "no" leg). In some cases, a single instruction bundle may be generated due to other bundle closure conditions such as those discussed below with respect to <FIG>. In embodiments in which the CIF <NUM> accumulates the command and/or implements the timer <NUM>, blocks <NUM> and/or <NUM> may be implemented in the CIF <NUM>, respectively.

<FIG> is a flowchart illustrating operation of one embodiment of the coprocessor issue circuit <NUM> for other processing related to bundling coprocessor instructions. While the blocks are shown in a particular order for ease of understanding, other orders may be used. Blocks, combinations of blocks, and/or the flowchart as a whole may be pipelined over multiple clock cycles. The coprocessor issue circuit <NUM>, or components thereof, may be configured to implement the operation illustrated in <FIG>.

The coprocessor issue circuit <NUM> may update the timer each clock cycle (e.g. decrementing the timer) while there is an open bundle (block <NUM>). If the timer expires (decision block <NUM>, "yes" leg), the coprocessor issue circuit <NUM> may close the bundle and transmit the command to the CIF <NUM> (block <NUM>). As mentioned previously, this operation many be implemented in the CIF <NUM>, in other embodiments.

Additionally, the presence of a barrier instruction in the instruction stream may cause the coprocessor issue circuit <NUM> to close the buffer and transmit the command to the CIF <NUM> (decision block <NUM>, "yes" leg and block <NUM>). The bundle may include coprocessor load/store instructions, which would need to complete before the barrier instruction completes. Generally, a barrier instruction may be an instruction that is defined in the instruction set architecture of the CPU processor <NUM> to cause, when executed, preceding memory operations in program order to be completed to a certain point before the barrier instruction completes. For example, the preceding memory operations may be completed to the point that they are "globally visible. " A memory operation may be globally visible if it is observed or observable to all other memory-accessing devices (e.g. other processors) in the system. In some embodiments, the CPU processor <NUM> may also ensure that no memory operations that are subsequent to the barrier in program order are permitted to be performed until the barrier instruction completes. In other embodiments, the barrier instruction may cause the bundle to close only if the bundle includes one or more coprocessor load/store instructions.

If the CPU processor <NUM> encounters a non-coprocessor load/store operation (e.g. a CPU load/store - decision block <NUM>, "yes" leg), the coprocessor issue circuit <NUM> may close the bundle and transmit the command to the CIF <NUM> (block <NUM>). The bundle may include coprocessor load/store instructions, which could access the same address as the non-coprocessor load/store instruction. In this context, load/store instructions may access the same address if at least one byte is accessed by both of the instructions. Such coprocessor load/store instructions may be required to complete before the non-coprocessor load/store instructions. In other embodiments, the non-coprocessor load/store operation may cause the closing of the bundle only if the bundle includes one or more coprocessor load/store instructions. In still other embodiments, the non-coprocessor load/store operation may cause the closing of the bundle only if the bundle includes at least one coprocessor load/store instruction to the same address as the non-coprocessor load/store instruction.

In embodiments in which the CIF <NUM> assembles the command, the coprocessor issue circuit <NUM> may transmit an indication that the bundle is closing and the CIF <NUM> may complete the command and close the bundle. In still other embodiments, the CIF <NUM> may implement the timer and close the bundle, even if the coprocessor issue circuit <NUM> (or other CPU processor hardware) detects the other closure reasons shown in <FIG>.

Turning now to <FIG>, a flowchart is shown illustrating operation of the CIF <NUM> for one embodiment. While the blocks are shown in a particular order for ease of understanding, other orders may be used. Blocks, combinations of blocks, and/or the flowchart as a whole may be pipelined over multiple clock cycles. The CIF <NUM>, or components thereof, may be configured to implement the operation illustrated in <FIG>.

If the CIF <NUM> receives one or more payloads (decision block <NUM>, "yes" leg), and there is an open buffer entry/bundle in the data buffer <NUM> (decision block <NUM>, "yes" leg), the CIF <NUM> may merge the payload(s) into the buffer entry at the offset(s) specified for those payloads (block <NUM>). If there is no open buffer entry (decision block <NUM>, "no" leg), but there is a data buffer entry available (decision block <NUM>, "yes" leg), the CIF <NUM> may allocate the available buffer entry and write the payload at the specified offset (block <NUM>). A buffer entry may be available if it is not currently allocated to another operation (e.g. another coprocessor instruction bundle, a cache line eviction, a fill request, etc.). That is, the buffer entry may be empty. Additionally, the CIF <NUM> may initialize the corresponding address buffer entry with data identifying the entry as a coprocessor instruction bundle. If there is no open buffer entry (decision block <NUM>, "no" leg), the CIF <NUM> may reject the payload (block <NUM>). There may be a mechanism in the interface between the CIF <NUM> and the coprocessor issue circuit <NUM> to communicate the rejection. For example, there may be an acknowledgement communicated from the CIF <NUM> to the coprocessor issue circuit <NUM> for each transmission, and the acknowledgement may be withheld. Alternatively, there may be a buffer full indication transmitted from the CIF <NUM> to the coprocessor issue circuit <NUM> and the buffer full indication may prevent the coprocessor issue circuit <NUM> from attempting to transmit a payload if there is no open buffer. In yet another alternative, a credit-based system may be used in which the CIF <NUM> issues one or more credits to the coprocessor issue circuit <NUM>, where each credit corresponds to an available data buffer entry. The coprocessor issue circuit <NUM> may issue coprocessor instructions to an open bundle or, if there is no open bundle, the coprocessor issue circuit <NUM> may issue coprocessor instructions if there is a credit for an available buffer entry.

If a command is received (decision block <NUM>, "yes" leg), the CIF <NUM> may merge the command into the buffer entry at offset zero and close the buffer entry/bundle (block <NUM>). The bundle is ready to transmit to the coprocessor <NUM>, and the CIF <NUM> may arbitrate the entry other buffer entries that are ready to transmit and ultimately transmit the bundle to the coprocessor <NUM>, at which time the buffer entry may be invalidated and may become available for use for another operation or instruction bundle. As discussed previously, the CIF <NUM> may accumulate the command in other embodiments. In such embodiments, the CIF <NUM> may determine that the buffer entry is to close (or may receive an indication to close the buffer entry) and may update the buffer entry with the command.

Turning now to <FIG>, a block diagram of another embodiment of the CPU processor <NUM>, the coprocessor <NUM>, and the L2 cache <NUM> is shown. In this embodiment, the CPU processor <NUM> includes a load/store unit (LSU <NUM>) that also serves as the coprocessor issue circuit <NUM> for this embodiment. More particularly, the store queue <NUM> included in the LSU <NUM> may serve as the instruction queue <NUM>, in addition to serving as a store queue for CPU store operations, as described in more detail below. Thus, the discussion above related to the coprocessor issue circuit <NUM> applies to the LSU <NUM> in this embodiment. That is, the LSU <NUM> may implement the operation described above for the coprocessor issue circuit <NUM>.

In the embodiment of <FIG>, the CPU processor <NUM> includes the instruction cache (ICache) <NUM> and one or more pipeline stages (illustrated as the ellipses in <FIG>, along with the load/store unit <NUM> and the CIF <NUM>, each of which may implement one or more pipeline stages of the pipeline). The LSU <NUM> may include a reservation station (RS) <NUM>, an address generation unit (AGU)/translation lookaside buffer (TLB) <NUM>, a load queue (LDQ) <NUM>, and the store queue (STQ) <NUM>. The reservation station <NUM> is coupled to a preceding pipeline state to receive load/store operations, coprocessor instructions, operand addresses, and other related data and is coupled to the AGU/TLB <NUM>. The AGU/TLB <NUM> is coupled to the DCache <NUM>, the LDQ <NUM>, and the STQ <NUM>. The LDQ <NUM> and STQ <NUM> are coupled to the DCache <NUM> and the CIF <NUM>. The CIF <NUM> is further coupled to the coprocessor <NUM>, the L2 cache <NUM>, and the DCache <NUM>.

In the embodiment of <FIG>, the coprocessor <NUM> may include an instruction buffer <NUM>, an X memory <NUM>, a Y memory <NUM>, a Z memory <NUM>, a compute circuit <NUM>, and a memory access interface <NUM> coupled to each other.

More particularly, the CPU processor <NUM> may be configured to transmit the coprocessor instructions/operations to the coprocessor <NUM> through the STQ <NUM> and the CIF <NUM>, in an embodiment. The CIF <NUM> may be configured as shown and described in <FIG>, and as mentioned above the STQ <NUM> may operate as the instruction queue <NUM> for coprocessor instructions. The STQ <NUM> may also store CPU store operations, which may be in program order in the STQ <NUM> with the various coprocessor instructions. In one embodiment, the coprocessor computation operations may be handled like CPU store operations in the CPU processor <NUM> until they reach the STQ <NUM> (except that the coprocessor compute operations may not include an address generation/translation in the AGU/TLB <NUM>, in some embodiments, and may not access the DCache <NUM>, in some embodiments). The coprocessor computation operations may be issued from the STQ <NUM> when no longer speculative, and may be transmitted through the CIF to <NUM> to the coprocessor <NUM>.

Coprocessor load/store operations may also be handled like CPU store operations in the CPU processor <NUM> until they reach the STQ <NUM>, in an embodiment. The coprocessor load/store operations may include an address generation and translation by the AGU/TLB <NUM> as well, allowing the addresses accessed by the coprocessor load/store operations to be known prior to issuance of the coprocessor load/store operations to the coprocessor <NUM>. The CPU processor <NUM> may use the coprocessor load/store addresses and addresses of CPU load/store operations to order CPU load/store operations and coprocessor load/store operations, even though the coprocessor load/store operations are actually executed in the coprocessor <NUM>, independent of the CPU processor <NUM> once issued to the coprocessor <NUM>.

Generally, CPU load/store operations and coprocessor operations may be received in the reservation station <NUM>, which may be configured to monitor the source operands of the operations to determine when they are available and then issue the operations to the AGU/TLB <NUM>. Some source operands may be available when the operations are received in the reservation station <NUM>, which may be indicated in the data received by the reservation station <NUM> for the corresponding operation. Other operands may become available via execution of operations by other execution units (e.g. integer execution units, floating point execution units, etc. not shown in <FIG>). The operands may be gathered by the reservation station <NUM>, or may be read from a register file (not shown in <FIG>) upon issue from the reservation station <NUM>.

In an embodiment, the reservation station <NUM> may be configured to issue operations out of order (from their original order in the code sequence being executed by the CPU processor <NUM>, referred to as "program order") as the operands become available. To ensure that there is space in the LDQ <NUM> or the STQ <NUM> for older operations that are bypassed by younger operations in the reservation station <NUM>, an earlier pipeline stage in the CPU processor <NUM> may include circuitry that preallocates LDQ <NUM> or STQ <NUM> entries to operations transmitted to the load/store unit <NUM>. For example, a register rename stage may assign rename registers to the architected registers specified in various instructions fetched by the CPU processor <NUM>. The register rename stage may include allocation of LDQ <NUM> or STQ <NUM> entries. Particularly, in one embodiment, CPU load operations may be assigned LDQ <NUM> entries and CPU store operations and coprocessor operations (load, store, and computation) may be assigned STQ <NUM> entries. In other embodiments, the reservation station <NUM> may issue operations in program order and LDQ <NUM>/STQ <NUM> assignment may occur at issue from the reservation station <NUM>.

It is noted that, for coprocessor operations, the source operands that are determined as available by the reservation station <NUM> may be operands that are stored in the CPU processor <NUM>. For example, the address operand(s) of the coprocessor load/store operations (which specify the address accessed by the load/store operations) may be stored in CPU registers (e.g. integer registers). The data source for a coprocessor store operation may be in the coprocessor <NUM> and may not be tracked by the reservation station <NUM>. Similarly, computation operations may have a CPU register (e.g. integer register) which specifies additional information about the instruction (the payload described above), in an embodiment, but the operands of the computation operation itself may be stored in the coprocessor <NUM> and may not be tracked in the reservation station <NUM>.

The AGU/TLB <NUM> may be configured to generate the address accessed by a load/store operation, and translate the address from an effective or virtual address created from the address operands of the load/store operation to a physical address actually used to address memory. The AGU/TLB <NUM> may be configured to generate an access to the DCache <NUM> for CPU load/store operations. For CPU load operations, data may be speculatively forwarded from the DCache <NUM> to the destination operand of the CPU load operation (e.g. a register in the CPU processor <NUM>, not shown in <FIG>), unless the address hits a preceding operation in the STQ <NUM> (that is, an older CPU store or coprocessor load/store operation in program order) or a memory ordering table used to order memory operations outstanding in the coprocessor <NUM> with CPU load/store memory operations. The cache hit/miss status from the DCache <NUM> may be logged for CPU store operations in the STQ <NUM> for later processing.

The CPU load operations may be written to the LDQ <NUM>, and the CPU store operations and coprocessor load/store operations may be written to the STQ <NUM>, to enforcing ordering among operations. The coprocessor computation operations may be ordered in the STQ <NUM> as well for program order, but may not have memory ordering considerations. In one embodiment, the instruction set architecture implemented by the CPU processor <NUM> and the coprocessor <NUM> may permit memory accesses to different addresses to occur out of order but may require memory accesses to the same address to occur in program order.

A memory ordering table (not shown) may be configured to track outstanding coprocessor load/store operations. A coprocessor load/store operation may be "outstanding" if it has been issued by the CPU processor <NUM> from the STQ <NUM> to the coprocessor <NUM> (including if it is in the CIF <NUM> awaiting transfer to the coprocessor <NUM> or in any other pipeline stage of the CPU processor <NUM> subsequent to issuance from the STQ <NUM>) and has not been completed by the coprocessor <NUM>. A memory operation may be completed by the coprocessor <NUM> when the data has been transferred between a location in one of the memories <NUM>, <NUM>, and <NUM> and main memory, although the transfer may be completed via a cache such as the L2 cache <NUM>, another cache between the L2 cache <NUM> and main memory, or main memory itself.

In an embodiment, the memory ordering table may be configured to track outstanding coprocessor load/store operations based on one or more memory regions that include the address accessed by the coprocessor load/store operations. The memory region may be a contiguous range of memory addresses that encompasses multiple cache lines of the caches in the system. For example, the memory region may be a page of memory, where the page size may be the size of a page translated by a given translation in the address translation mechanism used by the CPU processor <NUM> (e.g. the translation mechanism implemented in the TLB within the AGU/TLB <NUM> and related table walking circuitry when a TLB miss occurs). The page size may vary in various embodiments. For example, a <NUM> kilobyte page may be used. Other embodiments may user larger or smaller page sizes (e.g. <NUM> kilobytes, <NUM> kilobytes, <NUM> Megabyte, <NUM> Megabytes, etc.). Any page size may be used in an embodiment. In other embodiments, a memory region may be larger than a cache line but smaller than a page, or may be multiple pages. In still other embodiments, a memory region may be a cache line.

For CPU load/store operations, the memory ordering table may be consulted to detect if there are potentially outstanding coprocessor load/store operations to the same address. Since the memory ordering table tracks memory regions, it is possible that a potential ordering issue may be detected if addresses are in the same region by not actually overlapping. However, since ordering issues are expected to be rare between CPU load/store operations and coprocessor load/store operations, the performance impact of over-detecting ordering issues may be relatively small. Additionally, correct ordering in cases in which there is an overlap in the operations is provided.

Coprocessor load/store operations may also be issued from the STQ <NUM>, and may consult the LDQ <NUM> for potential ordering issues. However, the coprocessor load/store operations need not consult the memory ordering table for ordering, as the coprocessor <NUM> may be responsible for the ordering among coprocessor load/store operations. On the other hand, the coprocessor load/store operations may update the memory ordering table when issued from the STQ <NUM>, so that the coprocessor load/store operations may be tracked by the memory ordering table.

In one embodiment, the computation operations specified by the instructions implemented in the coprocessor <NUM> may be performed on vectors of input operands. For example, an embodiment receives vectors of operands from the X memory <NUM> and the Y memory <NUM>. The compute circuit <NUM> may include an array of compute elements (circuits) to perform the operations. Each circuit may receive a vector of elements from the X memory <NUM> and a vector of elements from the Y memory <NUM>, and may evaluate the operation on the vector elements. In an embodiment, the result of the operation may be accumulated with the current value in a corresponding location in the Z memory <NUM>, for write back to the corresponding location in the Z memory <NUM>. In an embodiment, the coprocessor <NUM> may also support a matrix mode for the compute instructions. In the matrix mode, an outer product of the input vector operands may be computed. In yet another embodiment, vectors of matrices (e.g. 2x2 matrices) may be supported as operands and matrix operations may be performed on the matrices in the vectors.

In an embodiment, the coprocessor <NUM> may support various data types and data sizes (or precisions). For example, floating point and integer data types may be supported. The floating point data type may include <NUM> bit, <NUM> bit, and <NUM> bit precisions. The integer data types may include <NUM> bit and <NUM> bit precisions, and both signed and unsigned integers may be supported. Other embodiments may include a subset of the above precisions, additional precisions, or a subset of the above precisions and additional precisions (e.g. larger or smaller precisions).

In an embodiment, the coprocessor load operations may transfer vectors from a system memory (not shown in <FIG>) to the X memory <NUM>, Y Memory <NUM>, or Z memory <NUM>. The coprocessor store operations may write the vectors from the X and Y memories <NUM> and <NUM> to system memory. The Z memory <NUM> may be written to memory using an extract instruction to move the results to the X memory <NUM> and/or the Y memory <NUM>, and then storing the results from the X memory <NUM> and/or the Y memory <NUM> to system memory. Alternatively, a store instruction to store the Z memory <NUM> to main memory may also be supported. The system memory may be a memory accessed at an end of the cache hierarchy that includes the caches <NUM>, <NUM>, and <NUM>. The system memory may be formed from a random access memory (RAM) such as various types of dynamic RAM (DRAM) or static RAM (SRAM). A memory controller may be included to interface to the system memory. In an embodiment, the coprocessor <NUM> may be cache coherent with the CPU processor <NUM>. In an embodiment, the coprocessor <NUM> may have access to the L2 cache <NUM>, and the L2 cache <NUM> may ensure cache coherency with the data cache <NUM>. In yet another alternative, the coprocessor <NUM> may have access to the memory system, and a coherence point in the memory system may ensure the coherency of the accesses. In yet another alternative, the coprocessor <NUM> may have access to the caches <NUM> and <NUM>. Any mechanism for accessing memory and ensuring coherency may be used in various embodiments.

Similarly, CPU load operations may specify transfer of data from a memory location to the CPU processor <NUM> (e.g. a register target in the CPU processor <NUM>). CPU store operations may specify the transfer of data from the CPU processor <NUM> to a memory location. Each load/store operation (whether CPU or coprocessor) may include one or more address operands specified by the corresponding instruction that may be added to produce the effective or virtual memory address of the memory location accessed by the load/store operation. The address operands may include immediate operands, operands stored in a CPU register, etc. The virtual address may then be translated to a physical address through the address translation mechanism, represented by the TLB.

The instruction buffer <NUM> may be provided to allow the coprocessor <NUM> to queue instructions while other instructions are being performed. In an embodiment, the instruction buffer <NUM> may be a first in, first out buffer (FIFO). That is, instructions may be processed in program order. Other embodiments may implement other types of buffers, multiple buffers for different types of instructions (e.g. load/store instructions versus compute instructions) and/or may permit out of order processing of instructions. The instruction buffer <NUM> may be configured to receive and store instruction bundles. For example, the instruction buffer <NUM> may have multiple entries, each of which may be configured to store an instruction bundle.

The X memory <NUM> and the Y memory <NUM> may each be configured to store at least one vector of input operands. Similarly, the Z memory <NUM> may be configured to store at least one computation result. The result may be an array of results at the result size (e.g. <NUM> bit elements or <NUM> bit elements). In some embodiments, the X memory <NUM> and the Y memory <NUM> may be configured to store multiple vectors and/or the Z memory <NUM> may be configured to store multiple result vectors. Each vector may be stored in a different bank in the memories, and operands for a given instruction may be identified by bank number. More generally, each entry in the memories <NUM>, <NUM>, and <NUM> may be addressed by a register address (e.g. register number) and thus the entries in the memories may be viewed as registers, similar to an integer or floating point register in the CPU processor <NUM> (although generally significantly larger than such a register in terms of storage capacity). Viewed in another way, each of the memories <NUM>, <NUM>, and <NUM> may be addressable as entries using addresses that are referenced to the particular memory (e.g. each memory <NUM>, <NUM>, and <NUM> may have its own address space). A given address of a given entry in the X memory <NUM>, for example, may have the same numerical value as a second given address of a second given entry in the Y memory <NUM>. Because they are coded in a given instruction as an X memory address or a Y memory address, the correct entry from the correct memory to be read/written may be selected by the coprocessor <NUM>.

The compute circuit <NUM> may be configured to perform the computation operations, as previously mentioned. The memory access interface <NUM> may be configured to perform the coprocessor load/store operations. The coprocessor <NUM> may provide the coprocessor load/store operations from the instruction buffer <NUM> to the memory access interface <NUM>, which may include a queue for the load/store operations and control logic to select the load/store operations for execution. The address of the coprocessor load/store operations may be provided with the operation from the CPU processor <NUM>, as previously noted. However, for coprocessor store operations, the source data from one of the memories <NUM>, <NUM>, and <NUM> may not be available until prior compute operations have been completed. Coprocessor load operations may generally be ready for execution when provided to the memory access interface <NUM>, but may have ordering constraints with younger coprocessor load/store operations. The memory access interface <NUM> may be configured to resolve the ordering constraints and transmit the memory operations to the L2 cache <NUM>.

In an embodiment, the L2 cache <NUM> may be configured to check for a cache hit for the coprocessor load/store operations, and may also determine if the data (or a portion thereof) accessed by the coprocessor load/store operations is in the DCache <NUM>. The L2 cache <NUM> may be inclusive of the DCache <NUM>, and thus the tag for the cache line in the L2 cache <NUM> may indicate if the cache line is in the DCache <NUM>. Alternatively, the L2 cache <NUM> may include a set of tags for the DCache <NUM> and may track which cache blocks are in the DCache <NUM> in the set of tags. If the data is in the DCache <NUM>, the L2 cache <NUM> may generate an operation to invalidate the DCache <NUM> cache line (and fetch the data if it is modified). This operation may be referred to as a "back snoop" operation. Additionally, the L2 cache <NUM> may detect a cache miss for a coprocessor load/store operation, and may fetch the missing cache line from another lower level cache or the main memory to complete the request.

At various points, load/store operations are referred to as being younger or older than other load/store operations. A first operation may be younger than a second operation if the first operation is subsequent to the second operation in program order. Similarly, a first operation may be older than a second operation if the first operation precedes the second operation in program order.

It is noted that the coprocessor <NUM> may be illustrated in simplified form, in an embodiment, and may include additional components not shown in <FIG>. For example, the coprocessor <NUM> may include a pipeline to decode coprocessor operations, perform register renaming on the operands, use a physical memory size for the X memory <NUM> and Y memory <NUM> that is larger than the architected size, and execute computation operations out of order. Any implementation of the coprocessor <NUM> may be used in various embodiments.

It is noted that, in some embodiments, the coprocessor <NUM> may be shared by multiple CPU processors <NUM>. The coprocessor <NUM> may maintain separate contexts in the X memory <NUM>, Y memory <NUM>, and Z memory <NUM> for each CPU processor <NUM>, for example. Alternatively, contexts may be swapped in the coprocessor <NUM> when different CPU processors <NUM> issue coprocessor operations to the coprocessor <NUM>. In an embodiment in which the CPU processor(s) <NUM> are multithreaded, there may be multiple contexts for a given CPU processor <NUM>.

In one embodiment, the same pipelines from the STQ <NUM> to the DCache <NUM>/CIF <NUM> to commit stores may also be used to transmit coprocessor instructions to the CIF <NUM> for bundling. This leads to several possibilities for the transmission of coprocessor and non-coprocessor operations (e.g. CPU store operations, cache maintenance operations, etc.) to the CIF <NUM>. <FIG> is a table <NUM> illustrating one embodiment of the possibilities and the operation that may be implemented when those possibilities occur. The table include pipe o and pipe <NUM> columns for the two store pipes that may be used in this embodiment, where pipe o handles an operation that is older in program order than a concurrently issued operation to pipe <NUM>. In each column, the abbreviation Cop is used for a coprocessor instruction and the abbreviation Non-Cop is used for a non-coprocessor instruction (e.g. CPU store or cache maintenance operation). The bundle status column indicates that status of the bundle in the CIF <NUM> (open, not open, not applicable). Actions for each pipe are then listed.

Thus, the first row of the table <NUM> illustrates coprocessor instruction followed by a non-coprocessor operation. The bundle status is not applicable in this case. Pipe o may carry the payload for the coprocessor instruction, and the command may be sent on pipe <NUM> (since a non-coprocessor operation causes the bundle to close). That is, if there is no open bundle, a bundle is opened for the coprocessor instruction and then closed because of the non-coprocessor instruction. The non-coprocessor instruction may be blocked on pipe o to permit transmission of the command. In embodiments in which the command is accumulated in the CIF <NUM>, the command may not be explicitly transmitted. Instead, the load/store unit <NUM> may signal the CIF <NUM> to close the bundle. There may be additional sideband signals between the load/store unit <NUM> and the CIF <NUM> to communicate the context ID and opcodes when payloads are transmitted to the CIF <NUM>, in such embodiments.

The second row of the table <NUM> illustrates a non-coprocessor operation followed by a coprocessor instruction with no open bundle. In this case, the non-coprocessor operation may be sent on pipe o and the payload for the coprocessor instruction may be sent on pipe <NUM>. The payload causes a new bundle to be opened and the payload corresponds to the first coprocessor instruction in the bundle. As illustrated in <FIG>, the non-coprocessor operation may be sent to either the DCache <NUM> or the CIF <NUM>. On the other hand, the third row of table <NUM> illustrates the same set of operations but an open bundle. In this case, both the non-coprocessor operation and the coprocessor instruction may be blocked, and the command may be sent on pipe o to close the bundle. In embodiments in which the command is accumulated in the CIF <NUM>, the command may not be explicitly transmitted. Instead, the load/store unit <NUM> may signal the CIF <NUM> to close the bundle. In a subsequent clock cycle, the second row of the table <NUM> may apply.

The fourth and fifth rows of the table <NUM> illustrate two coprocessor instructions ready to issue on pipes o and <NUM>. There are two possibilities in this embodiment, either there is room for two instructions in the bundle or there is room for one instruction. If there is room for two instructions, the fourth row applies. The payloads for the two instructions may be merged and transmitted on pipe o. That is, the pipes may have a data width that is wide enough to transmit two payloads, and the width may be used in this case to transmit both payloads so that the command may be transmitted on pipe <NUM> concurrently if the bundle is complete. In embodiments in which the command is accumulated in the CIF <NUM>, the command may not be explicitly transmitted. Instead, the load/store unit <NUM> may signal the CIF <NUM> to close the bundle. If the bundle is not complete (there is at least one open slot in the bundle for another coprocessor instruction), the command may not be transmitted and the bundle may remain open. If there is only one open slot in the bundle, the payload for the first coprocessor instruction may be sent on pipe o and pipe <NUM> may be blocked. The command may be merged with the payload on pipe o to close the buffer (or the CIF <NUM> may be signaled to close the bundle, in embodiments in which the CIF <NUM> generates the command).

The sixth and seventh rows of the table illustrate two non-coprocessor operations to be issued on pipe o and pipe <NUM>. If there is no open bundle of coprocessor instructions (sixth row), the two non-coprocessor operations may be sent on pipe o and pipe <NUM>. As illustrated in <FIG>, the non-coprocessor operations may be sent to either the DCache <NUM> or the CIF <NUM>. If there is an open bundle coprocessor instructions (seventh row), both non-coprocessor ops may be blocked and the command may be transmitted on pipe o. In embodiments in which the command is accumulated in the CIF <NUM>, the command may not be explicitly transmitted. Instead, the load/store unit <NUM> may signal the CIF <NUM> to close the bundle. In a subsequent clock cycle, the sixth row may apply.

In another embodiment, the CPU processor <NUM> may support two pipes from the STQ <NUM> to the CIF <NUM> but the coprocessor <NUM> may be able to consume more than two coprocessor instructions per clock cycle (e.g. <NUM> instructions). The CPU processor <NUM> may support coprocessor instruction fusion in this case, in which one instruction flowing through the CPU processor pipeline represents two coprocessor instructions (and thus has two opcodes and two payloads). As mentioned above, in an embodiment, the data interface between the STQ <NUM> and the CIF <NUM> may be wide enough to carry two payloads. The STQ <NUM> may also include storage for up to two payloads in an entry. Thus, a given issuance from the STQ <NUM> may be two coprocessor instructions. The instructions may be fused in the early stages of the pipeline of the CPU processor <NUM>, and may effectively become unfused when the payloads are written to different slots in the bundle.

Using fused coprocessor instructions, up to four coprocessor instructions may be issued per clock cycle (e.g. if two fused coprocessor instructions are consecutive in the STQ <NUM>). Thus, a bundle of six or seven coprocessor instructions may be formed in a minimum of <NUM> clock cycles, if fused ops are prevalent in the instruction stream. For example, two fused instructions may be issued in one clock cycle (<NUM> total instructions) followed by one fused instruction and optionally on non-fused instruction (<NUM> or <NUM> total instructions) to form a bundle of <NUM> or <NUM> coprocessor instructions. That rate of bundle formation may supply an average of <NUM> instructions per clock cycle.

Instructions may be fused only if they are consecutive in the program order of the instruction stream, in an embodiment. Thus, there may be both fused and unfused coprocessor instructions in the STQ <NUM>. <FIG> is a table <NUM> illustrating one embodiment of the number of coprocessor instructions in the bundle prior to issue (bundle count), fused and unfused coprocessor instructions ready to issue on pipe o and pipe <NUM>, respectively (marked as NF for unfused and F for fused in the pipe o and pipe <NUM> columns), whether or not the bundle is closed after issuance of the coprocessor instructions, and whether or not the coprocessor instruction is blocked on pipe o or pipe <NUM>. The presence of a zero in the close bundle column for a given row means the bundle remains open, and the presence of a <NUM> means the bundle is closed. Closing the bundle may imply transmitting the command to the CIF <NUM> or, in embodiments in which the CIF <NUM> generates the command, closing the bundle may imply signaling from the load/store unit <NUM> to the CIF <NUM> to close the bundle. The presence of a zero in the block o or block <NUM> columns means the corresponding pipe o or pipe <NUM> is not blocked (e.g. the coprocessor instruction is issued). The presence of a one in the block o or block <NUM> column means the corresponding pipe o or pipe <NUM> is blocked (e.g. the coprocessor instruction is not issued). The table of <FIG> may still apply for cases of coprocessor and non-coprocessor instructions that are concurrently ready for issue.

In general, the bundle may be closed if, after issue of the instructions for a given row, there are no slots left in the bundle or there is only one slot left in the bundle. If there are no slots left in the bundle, the bundle is full and therefore complete. If there is only one slot left in the bundle, a fused coprocessor instruction would not be able to be issued because it needs two slots for the two fused instructions. Furthermore, waiting an additional clock cycle for one possible instruction may negatively impact the average of three instructions per clock cycle that the bundling is attempting to accomplish.

If the current bundle count is zero or one, there is no restriction on the issuance of fused or non-fused coprocessor instructions since even if two fused coprocessor instructions are issued, there would still be two slots left in the seven slots used in one embodiment. These entries are not listed in the table. Similarly, if the current bundle count is two, any combination of two unfused coprocessor instructions or one fused and one unfused coprocessor instruction may be issued and still leave two open slots. However, if the bundle count is two and two fused coprocessor instructions are issued, the bundle count becomes six (first row of the table <NUM>). In this case, the command still remains to be issued to the CIF <NUM>, so the bundle is not closed yet. In a subsequent clock cycle, the command may be issued and the bundle may be closed. In yet another embodiment, the command may be transmitted concurrent with the payloads and the bundle may be closed. Accordingly, the close bundle column is shown as <NUM>/<NUM> to illustrate the two possibilities. In still another embodiment in which the CIF <NUM> accumulates the command, the command may not be explicitly transmitted and the bundle may be closed via signaling from the load/store unit <NUM> to the CIF <NUM>. Alternatively, the bundle may not be closed and the STQ <NUM> may attempt another issuance with the bundle count equal to six, and the rows of the table <NUM> with the bundle count of six may apply.

Similarly, if the current bundle count is three and two fused coprocessor instructions are ready to issue, (fourth row of the table <NUM>), the coprocessor instructions may be issued and a subsequent clock cycle may be used to issue the command, in which the last row of the table <NUM> may apply. Alternatively, as mentioned above, in another embodiment the command may be transmitted concurrent with the payloads and the bundle may be closed. In embodiments in which the CIF <NUM> generates the bundle, there may be no transmission of the command and the load/store unit <NUM> may signal the CIF <NUM> to close the bundle. Accordingly, the close bundle column is shown as <NUM>/<NUM> to illustrate the two possibilities. Other scenarios with three instructions in the current bundle count (second and third rows of the table <NUM>) may cause the bundle to close with a total of six coprocessor instructions. The command may be transmitted with the unfused instruction (pipe o for the second row, pipe <NUM> for the third row).

If the current bundle count is <NUM>, any combination that results in two or more coprocessor instructions being transmitted causes the bundle to close. The command may be sent on pipe <NUM> in each case except the second case of bundle count of <NUM> (sixth row of the table <NUM>), in which case it is sent with the unfused instruction on pipe o. The combination of two fused coprocessor instructions causes a block on pipe <NUM> because the second of the fused instructions may not fit in the bundle. The command is issued on pipe <NUM> instead in this case. In embodiments in which the CIF <NUM> generates the command, the command may not be sent explicitly and instead the load/store unit <NUM> may signal the CIF <NUM> to close the bundle.

With a current bundle count of <NUM>, any combination of one or more coprocessor instructions completes the bundle. Combinations of three total coprocessor instructions cause pipe <NUM> to be blocked. In each case, the command may be issued on pipe <NUM> (along with a non-fused coprocessor instruction or no coprocessor instruction in the tenth, eleventh, and thirteenth rows of the table <NUM> or instead of the instruction in the twelfth, fourteenth, and fifteenth rows of the table <NUM>). In embodiments in which the CIF <NUM> generates the command, the command may not be sent explicitly and instead the load/store unit <NUM> may signal the CIF <NUM> to close the bundle.

With a current bundle count of <NUM>, only one non-fused coprocessor may be transmitted on pipe o (sixteenth to eighteenth rows of table <NUM>). The command is issued on pipe <NUM> with either no coprocessor instruction (sixteenth row) or in place of the blocked coprocessor instruction (seventeenth and eighteenth rows). The nineteenth row represents a case where both pipes are blocked and the command is sent on pipe o. In embodiments in which the CIF <NUM> generates the command, the command may not be sent explicitly and instead the load/store unit <NUM> may signal the CIF <NUM> to close the bundle.

The last row of the table <NUM> illustrates a case in which the bundle is full (current bundle count of <NUM>). Both pipes are blocked and the command may be transmitted on pipe o in this case. In embodiments in which the CIF <NUM> generates the command, the command may not be sent explicitly and instead the load/store unit <NUM> may signal the CIF <NUM> to close the bundle.

<FIG> is a block diagram of one embodiment of a system <NUM>. In the illustrated embodiment, the system <NUM> includes at least one instance of an integrated circuit (IC) <NUM> coupled to one or more peripherals <NUM> and an external memory <NUM>. A power supply <NUM> is provided which supplies the supply voltages to the IC <NUM> as well as one or more supply voltages to the memory <NUM> and/or the peripherals <NUM>. The IC <NUM> may include one or more instances of the CPU processor <NUM> and one or more instances of the coprocessor <NUM>. In other embodiments, multiple ICs may be provided with instances of the CPU processor <NUM> and/or the coprocessor <NUM> on them.

The peripherals <NUM> may include any desired circuitry, depending on the type of system <NUM>. For example, in one embodiment, the system <NUM> may be a computing device (e.g., personal computer, laptop computer, etc.), a mobile device (e.g., personal digital assistant (PDA), smart phone, tablet, etc.), or an application specific computing device capable of benefitting from the coprocessor <NUM> (e.g., neural networks, LSTM networks, other machine learning engines including devices that implement machine learning, etc.). In various embodiments of the system <NUM>, the peripherals <NUM> may include devices for various types of wireless communication, such as wifi, Bluetooth, cellular, global positioning system, etc. The peripherals <NUM> may also include additional storage, including RAM storage, solid state storage, or disk storage. The peripherals <NUM> may include user interface devices such as a display screen, including touch display screens or multitouch display screens, keyboard or other input devices, microphones, speakers, etc. In other embodiments, the system <NUM> may be any type of computing system (e.g. desktop personal computer, laptop, workstation, net top etc.).

The external memory <NUM> may include any type of memory. For example, the external memory <NUM> may be SRAM, dynamic RAM (DRAM) such as synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM, RAMBUS DRAM, low power versions of the DDR DRAM (e.g. LPDDR, mDDR, etc.), etc. The external memory <NUM> may include one or more memory modules to which the memory devices are mounted, such as single inline memory modules (SIMMs), dual inline memory modules (DIMMs), etc. Alternatively, the external memory <NUM> may include one or more memory devices that are mounted on the IC <NUM> in a chip-on-chip or package-on-package implementation.

<FIG> is a block diagram of one embodiment of a computer accessible storage medium <NUM> is shown storing an electronic description of the IC <NUM> (reference numeral <NUM>). More particularly, the description may include at least the coprocessor <NUM> and/or the CPU processor <NUM>. Generally speaking, a computer accessible storage medium may include any storage media accessible by a computer during use to provide instructions and/or data to the computer. For example, a computer accessible storage medium may include storage media such as magnetic or optical media, e.g., disk (fixed or removable), tape, CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, or Blu-Ray. Storage media may further include volatile or non-volatile memory media such as RAM (e.g. synchronous dynamic RAM (SDRAM), Rambus DRAM (RDRAM), static RAM (SRAM), etc.), ROM, or Flash memory. The storage media may be physically included within the computer to which the storage media provides instructions/data. Alternatively, the storage media may be connected to the computer. For example, the storage media may be connected to the computer over a network or wireless link, such as network attached storage. The storage media may be connected through a peripheral interface such as the Universal Serial Bus (USB). Generally, the computer accessible storage medium <NUM> may store data in a non-transitory manner, where non-transitory in this context may refer to not transmitting the instructions/data on a signal. For example, non-transitory storage may be volatile (and may lose the stored instructions/data in response to a power down) or non-volatile.

Generally, the electronic description <NUM> of the IC <NUM> stored on the computer accessible storage medium <NUM> may be a database which can be read by a program and used, directly or indirectly, to fabricate the hardware comprising the IC <NUM>. For example, the description may be a behavioral-level description or register-transfer level (RTL) description of the hardware functionality in a high level design language (HDL) such as Verilog or VHDL. The description may be read by a synthesis tool which may synthesize the description to produce a netlist comprising a list of gates from a synthesis library. The netlist comprises a set of gates which also represent the functionality of the hardware comprising the IC <NUM>. The netlist may then be placed and routed to produce a data set describing geometric shapes to be applied to masks. The masks may then be used in various semiconductor fabrication steps to produce a semiconductor circuit or circuits corresponding to the IC <NUM>. Alternatively, the description <NUM> on the computer accessible storage medium <NUM> may be the netlist (with or without the synthesis library) or the data set, as desired.

While the computer accessible storage medium <NUM> stores a description <NUM> of the IC <NUM>, other embodiments may store a description <NUM> of any portion of the IC <NUM>, as desired (e.g. the coprocessor <NUM> and/or the CPU processor <NUM>, as mentioned above).

Claim 1:
A system (<NUM>) comprising:
a processor (<NUM>) including:
a coprocessor issue circuit (<NUM>) configured to issue coprocessor instructions to an interface circuit (<NUM>) for transmission to a coprocessor (<NUM>); and
the interface circuit (<NUM>), wherein the interface circuit (<NUM>) is coupled to the coprocessor issue circuit (<NUM>) and includes a buffer having a plurality of buffer entries, wherein the interface circuit (<NUM>) is configured to accumulate, in a buffer entry (<NUM>) of the plurality of buffer entries, data describing multiple ones of the coprocessor instructions, wherein the data identifies, for a given one of the multiple coprocessor instructions, an opcode and a payload, and wherein the data includes respective source data specified by one or more of the multiple coprocessor instructions;
wherein the interface circuit (<NUM>) is further configured to write a command to the buffer entry (<NUM>), close the buffer entry (<NUM>), and transmit the buffer entry's contents to the coprocessor (<NUM>), and wherein the command comprises opcodes corresponding to respective ones of the multiple coprocessor instructions; and
the coprocessor (<NUM>), wherein the coprocessor (<NUM>) is configured to execute the coprocessor instructions, wherein the coprocessor (<NUM>) is configured to execute the coprocessor instructions at up to a first rate, and wherein the interface circuit (<NUM>) is configured to provide the coprocessor instructions at an average rate that matches the first rate.