Pseudo FIFO tag line replacement

Abstract

The present application is entitled “Pseudo First-In-First-Out (FIFO) Tag Line Replacement.” A method is provided that includes searching a tag (4000) included in a tag group (4008) in a tagged memory system for an available tag line during a clock cycle, wherein the tagged memory system includes a plurality of tag lines having corresponding tags, and wherein the tags are divided into a plurality of non-overlapping tag groups, and searching a tag (4000) in a next tag group (4010) of the plurality of tag groups for an available tag line during a next clock cycle when no available tag line is found (4008) during the search in the tag group.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 851,418, filed May 22, 2019, which is incorporated herein by reference in its entirety. Background Art

[0003] Digital signal processors (DSPs) are optimized for processing data streams that can be derived from a variety of input signals, such as sensor data, video streams, voice channels, radar signals, biomedical signals, and the like. A digital signal processor operating on real-time data typically receives an input data stream, performs a filtering function (such as encoding or decoding) on ​​the data stream, and outputs a converted data stream. The system is called real-time because the application fails if the converted data stream is not available for output when it is scheduled. Typical video encoding requires a predictable but non-sequential input data pattern. Typical applications require memory access to load data registers in a data register file (RF) and then supply data from the data registers to the functional units that perform the data processing.

[0004] One or more DSP processing cores can be combined with various peripheral circuits, memory blocks, etc. on a single integrated circuit (IC) die to form a system on a chip (SoC). These systems can include multiple interconnected processors that share the use of on-chip and off-chip memory. The processors can include some combination of instruction cache (ICache) and data cache (DCache) to improve processing power. In addition, multiple processors with shared memory can be merged into a single embedded system. The processors can physically share the same memory without accessing data located at the same memory location or executing code located at the same memory location, or the processors can use certain parts of the shared memory as common shared memory. Summary of the Invention

[0005] Embodiments of the present disclosure relate to methods and systems for pseudo FIFO tag line replacement strategies. In one aspect, a method is provided, comprising: searching a tag in a tag group included in a tagged memory system for an available tag line during a clock cycle, wherein the tagged memory system includes a plurality of tag lines having corresponding tags, and wherein the tags are divided into a plurality of non-overlapping tag groups; and when no available tag line is found during the search in the tag group, searching a tag in a next tag group of the plurality of tag groups for the available tag line during a next clock cycle.

[0006] In one aspect, a tagged memory system is provided, comprising: a plurality of tag lines; a plurality of tags, wherein each tag is associated with a corresponding tag line in the plurality of tag lines, and the plurality of tags are divided into non-overlapping tag groups; and a storage dispatch component configured to perform a pseudo first-in-first-out (FIFO) tag replacement, wherein during one clock cycle, a tag group in the plurality of tag groups is searched for an available tag line, and when no available tag line is found in the search in the tag group, a next tag group in the plurality of tag groups is searched for an available tag line during a next clock cycle.

[0007] In one aspect, a tagged memory system is provided, comprising: a plurality of tag lines; a plurality of tags, wherein each tag is associated with a corresponding tag line in the plurality of tag lines, and the plurality of tags are divided into non-overlapping tag groups; and a memory dispatch component configured to search each of the plurality of tag groups in a round-robin order until an available tag line is located or all tag groups have been searched, wherein the search begins with a tag group that includes a tag associated with a tag line dispatched in a previous search, and wherein each searched tag group is searched in a single clock cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 An example dual scalar / vector datapath processor is described;

[0009] Figure 2 illustrate Figure 1 registers and functional units in a dual scalar / vector datapath processor as described in;

[0010] Figure 3 Describe the global scalar register file;

[0011] Figure 4 Describes the local scalar register files shared by the algorithm functional units;

[0012] Figure 5 Describes a local scalar register file shared by the multiplication functional units;

[0013] Figure 6 Describes the local scalar register file shared by the local / storage units;

[0014] Figure 7 Describe the global vector register file;

[0015] Figure 8 Describe the assertion register file;

[0016] Figure 9 Describes the local vector register file shared by the algorithmic functional units;

[0017] Figure 10 describing a local vector register file shared by a multiplication functional unit and associated functional units;

[0018] Figure 11 Describe the pipeline stages of the processing unit;

[0019] Figure 12 Sixteen instructions describing a single extraction packet;

[0020] Figure 13 Examples illustrating instruction encoding;

[0021] Figure 14 Explain the bit encoding of condition code extension slot 0;

[0022] Figure 15 Explain the bit encoding of condition code extension gap 1;

[0023] Figure 16 The bit encoding 0 indicates the constant extension gap;

[0024] Figure 17 is a partial block diagram illustrating constant expansion;

[0025] Figure 18 Describes carry control for SIMD operations;

[0026] Figure 19 Explain the conceptual view of the stream engine;

[0027] Figure 20 Describes a sequence of formatting operations;

[0028] Figure 21 An example illustrating channel assignment in a vector;

[0029] Figure 22 An example illustrating channel assignment in a vector;

[0030] Figure 23 Describe basic two-dimensional (2D) flow;

[0031] Figure 24 illustrate Figure 23 The order of elements in the example stream;

[0032] Figure 25 Instructions for taking a smaller rectangle out of a larger rectangle;

[0033] Figure 26 Describes how the example stream engine extracts a stream with a 4-byte shift granularity;

[0034] Figure 27 Describes how the example stream engine extracts a stream with an 8-byte shift granularity;

[0035] Figure 28 Describe the details of the stream engine of the present invention;

[0036] Figure 29 Describe the example flow template register;

[0037] Figure 30 illustrate Figure 29 Example flow template register's tag field's subfield definitions;

[0038] Figure 31 Examples illustrating vector length mask / group repeat blocks;

[0039] Figure 32 is a partial schematic diagram of an example of generating a valid or invalid indication of a stream engine;

[0040] Figure 33 is a partial schematic diagram illustrating a stream engine address generator for generating a loop address and a loop count;

[0041] Figure 34 A partial schematic diagram illustrating the flow engine supply data of this example is described;

[0042] Figure 35 A partial schematic diagram illustrating a flow engine supplying valid data to an assertion unit is illustrated;

[0043] Figure 36 An example illustrating the first-in, first-out (FIFO) tag replacement strategy;

[0044] Figure 37-Figure 39 An example illustrating a pseudo-FIFO tag replacement strategy used by an example streaming engine;

[0045] Figure 40 is a flow chart of a method for label line replacement;

[0046] Figure 41 and Figure 42 is an example illustrating a priority encoder search for available label lines;

[0047] Figure 43 is a flow chart of a method for label line replacement;

[0048] Figure 44 is an example illustrating a priority encoder search for two available tag lines; and

[0049] Figure 45 It is a block diagram of a multiprocessor system. DETAILED DESCRIPTION

[0050] Like elements in the various drawings are denoted by like reference numerals for consistency.

[0051] Digital signal processors (DSPs) are optimized to process data streams derived from a variety of input signals, such as sensor data, video streams, voice channels, radar signals, biomedical signals, and more. Memory bandwidth and scheduling are important for digital signal processors operating on real-time data. This article describes an example DSP processing core that includes a streaming engine for improving memory bandwidth and data scheduling.

[0052] One or more DSP processing cores can be combined with various peripheral circuits, memory blocks, etc. on a single integrated circuit (IC) die to form a system on a chip (SoC). See, for example, the "66AK2Hx Multicore Keystone TM System-on-Chips,” 2013, which is incorporated herein by reference.

[0053] In the example DSP core described herein, an autonomous stream engine (SE) is coupled to the DSP. In this example, the stream engine includes two tightly coupled functional blocks that can manage two data streams simultaneously. In another example, the stream engine is capable of managing only a single stream, while in other examples, the stream engine is capable of handling more than two streams. In each case, for each stream, the stream engine includes an address generation stage, a data formatting stage, and some storage for formatted data waiting to be consumed by the processor. In the examples described herein, addresses are derived from algorithms that may involve multi-dimensional loops, with iteration counts maintained for each dimension. In one example, the stream engine supports six levels of nested iterations. In other examples, more or fewer iteration levels are supported.

[0054] Furthermore, in the examples described herein, the stream engine maintains an array of slots for each stream, each of which has a tag. Tagged slots are also referred to herein as tag lines. The stream engine uses tags to manage the storage of data in the slots. More specifically, when new data is received from a stream, the stream engine applies a pseudo first-in, first-out (FIFO) replacement strategy to identify available slots. As explained in more detail herein, the pseudo-FIFO replacement strategy tends to dispatch slots in FIFO order, but avoids stalling if a particular usage pattern operates against the FIFO order.

[0055] References Figures 1 to 18 An example DSP processor is described in detail. Figures 19 to 35 Describes in detail an example stream engine that can manage two data streams using six-dimensional nested loops. Figures 36 to 44 An example of a pseudo FIFO tag line replacement strategy is described in detail.

[0056] Figure 1An example processor 100 is illustrated that includes dual scalar / vector data paths 115, 117. The processor 100 includes a stream engine 125, which is described in more detail herein. The processor 100 includes a separate level 1 instruction cache (L1I) 121 and a level 1 data cache (L1D) 123. The processor 100 includes a level 2 combined instruction / data cache (L2) 130 that holds both instructions and data. Figure 1 The connection between the L1I cache and the L2 combined instruction / data cache 130 (512-bit bus 142) is illustrated. Figure 1 The connection between the L1D cache 123 and the L2 combined instruction / data cache 130 (512-bit bus 145) is illustrated. In the example processor 100, the L2 combined instruction / data cache 130 stores both instructions to back up the L1I cache 121 and data to back up the L1D cache 123. In this example, the L2 combined instruction / data cache 130 further uses Figure 1 Memory system technologies not described herein, whether known or later developed, are connected to higher-level caches and / or main memory. As used herein, the term "higher-level" memory or cache refers to the next level in the memory hierarchy that is further away from the processor, while the term "lower-level" memory or cache refers to the level in the memory hierarchy that is closer to the processor. In various examples, the L1I cache 121, the L1D cache 123, and the L2 cache 130 can be implemented in different sizes. In this example, the L1I cache 121 and the L1D cache 123 are each 32K bytes, and the L2 cache 130 is 1024K bytes. In the example processor 100, the L1I cache 121, the L1D cache 123, and the L2 combined instruction / data cache 130 are formed on a single integrated circuit. The single integrated circuit optionally includes other circuits.

[0057] Processing unit core 110 fetches instructions from L1I cache 121 under the control of instruction fetch unit 111. Instruction fetch unit 111 determines the next instruction to be executed and calls a fetch packet size for a set of such instructions. The nature and size of the fetch packet are further detailed below. If these instructions are stored in L1I cache 121, then after a cache hit, the instructions are fetched directly from L1I cache 121. If a cache miss occurs when the specified instruction is not stored in L1I cache 121, these instructions are searched for in L2 combined cache 130. In this example, the size of the cache line in L1I cache 121 is equal to the fetch packet size, i.e., 512 bits. The memory location of these instructions is either a hit or a miss in L2 combined cache 130. A hit is serviced by L2 combined cache 130. A miss is serviced by a higher-level cache (not shown) or by main memory (not shown). In this example, the requested instruction is supplied to both the L1I cache 121 and the processing unit core 110 simultaneously to accelerate usage.

[0058] In this example, the processing unit core 110 includes multiple functional units to perform the data processing tasks specified by the instructions. The instruction dispatch unit 112 determines the target functional unit for each extracted instruction. In this example, the processing unit 110 operates as a very long instruction word (VLIW) processor, which is capable of processing multiple instructions in the corresponding functional unit simultaneously. The compiler organizes the instructions to be executed together in the execution package. The instruction dispatch unit 112 directs each instruction to its target functional unit. The functional unit assigned to the instruction is completely specified by the instructions generated by the compiler. The hardware of the processing unit core 110 does not participate in this functional unit allocation. In this example, the instruction dispatch unit 112 operates on several instructions in parallel. The number of such parallel instructions is set by the size of the execution package. This is further described herein.

[0059] Part of the dispatching task of the instruction dispatch unit 112 is to determine whether the instruction is executed on a functional unit in the scalar datapath side A 115 or a functional unit in the vector datapath side B 116. An instruction bit in each instruction, called the s bit, determines which datapath the instruction controls. This is further described herein.

[0060] The instruction decode unit 113 decodes each instruction in the currently executing packet. Decoding includes identifying the functional unit that executes the instruction, identifying the registers from the possible register file (RF) that are used to supply data for the corresponding data processing operation, and identifying the register destination for the result of the corresponding data processing operation. As explained further below, an instruction may include a constant field in place of a register number operand field. The results of this decoding are signals that are used to control the target functional unit to perform the data processing operation specified by the corresponding instruction on the specified data.

[0061] The processing unit core 110 includes control registers 114. The control registers 114 store information for controlling functional units in the scalar datapath side A 115 and the vector datapath side B 116. This information may include mode information, etc.

[0062] The decoded instructions from the instruction decoder 113 and the information stored in the control register 114 are supplied to the scalar datapath side A 115 and the vector datapath side B 116. As a result, the functional units in the scalar datapath side A 115 and the vector datapath side B 116 perform the data processing operation specified by the instruction according to the data specified by the instruction and store the result in one or more data registers specified by the instruction. Each of the scalar datapath side A 115 and the vector datapath side B 116 includes a plurality of functional units operating in parallel. These are combined Figure 2 Further described, a data path 117 exists between the scalar data path side A 115 and the vector data path side B 116 to allow data exchange.

[0063] Processing unit core 110 further includes non-instruction-based modules. Simulation unit 118 allows the machine state of processing unit core 110 to be determined in response to instructions. This capability can be used for algorithm development. Interrupt / exception unit 119 enables processing unit core 110 to respond to external asynchronous events (interrupts) and to respond to attempts to perform inappropriate operations (exceptions).

[0064] The processor 100 includes a stream engine 125. The stream engine 125 supplies two data streams from predetermined addresses cached in the L2 combined buffer 130 to the register file of the vector data path side B of the processing unit core 110. This provides controlled data movement from memory (such as cached in the L2 combined buffer 130) directly to the operand inputs of the functional units. This is further described herein.

[0065] Figure 1 This figure illustrates example data widths for buses between various components. The L1I cache 121 supplies instructions to the instruction fetch unit 111 via bus 141. In this example, bus 141 is a 512-bit bus. Bus 141 runs unidirectionally from the L1I cache 121 to the processing unit 10. The L2 combining cache 130 supplies instructions to the L1I cache 121 via bus 142. In this example, bus 142 is a 512-bit bus. Bus 142 runs unidirectionally from the L2 combining cache 130 to the L1I cache 121.

[0066] The L1D cache 123 exchanges data with the register file in the scalar datapath side A 115 via bus 143. In this example, bus 143 is a 64-bit bus. The L1D cache 123 exchanges data with the register file in the vector datapath side B 116 via bus 144. In this example, bus 144 is a 512-bit bus. Buses 143 and 144 are illustrated as bidirectionally supporting both data reads and data writes from the processing unit core 110. The L1D cache 123 exchanges data with the L2 combined cache 130 via bus 145. In this example, bus 145 is a 512-bit bus. Bus 145 is illustrated as bidirectionally supporting cache services for both data reads and data writes from the processing unit core 110.

[0067] After a cache hit (if the requested data is stored in the L1D cache 123), the processor data request is directly retrieved from the L1D cache 123. After a cache miss (the specified data is not stored in the L1D cache 123), the data is searched for in the L2 combined cache 130. The memory location of the requested data is either a hit or a miss in the L2 combined cache 130. A hit is serviced by the L2 combined cache 130. A miss is serviced by another level of cache (not shown) or by main memory (not shown). The requested data can be supplied to both the L1D cache 123 and the processing unit core 110 simultaneously to accelerate its use.

[0068] The L2 combined buffer 130 supplies data for the first data stream to the stream engine 125 via bus 146. In this example, bus 146 is a 512-bit bus. The stream engine 125 supplies data for the first data stream to the functional units on the vector datapath side B 116 via bus 147. In this example, bus 147 is a 512-bit bus. The L2 combined buffer 130 supplies data for the second data stream to the stream engine 125 via bus 148. In this example, bus 148 is a 512-bit bus. The stream engine 125 supplies data for the second data stream to the functional units on the vector datapath side B 116 via bus 149. In this example, bus 149 is a 512-bit bus. In this example, buses 146, 147, 148, and 149 are illustrated as unidirectional from the L2 combined buffer 130 to the stream engine 125 and to the vector datapath side B 116.

[0069] After a cache hit (if the requested data is stored in the L2 combined cache 130), the stream engine data request is directly retrieved from the L2 combined cache 130. After a cache miss (the specified data is not stored in the L2 combined cache 130), the data is sought from another level of cache (not shown) or from main memory (not shown). In some examples, it is technically feasible for the L1D cache 123 to cache data not stored in the L2 combined cache 130. If this operation is supported, then based on the stream engine data request that was missed in the L2 combined cache 130, the L2 combined cache 130 snoops the L1D cache 1233 for the data requested by the stream engine. If the L1D cache 123 stores the data, the snoop response includes the data that is subsequently supplied to service the stream engine request. If the L1D cache 123 does not store the data, the snoop response indicates this and the L2 combining cache 130 services the stream engine request from another level of cache (not shown) or from main memory (not shown).

[0070] In this example, both L1D cache 123 and L2 combined cache 130 may be configured as a selected number of caches or directly addressable memories in accordance with U.S. Patent No. 6,606,686, entitled “Unified Memory System Architecture Including Cache and Directly Addressable Static Random Access Memory,” which is incorporated herein by reference.

[0071] In this example, processor 100 is fabricated on an integrated chip (IC) mounted on a ball grid array (BGA) substrate. The BGA substrate and IC die together may be referred to as a "BGA package," "IC package," "integrated circuit," "IC," "chip," "microelectronic device," or similar terms. The BGA package may include encapsulation material to cover and protect the IC die from damage. In another example, other types of known or later developed packaging technologies may be used with processor 100.

[0072] Figure 2The following further describes the details of the functional units and register files in the scalar datapath side A115 and the vector datapath side B116. The scalar datapath side A115 includes the L1 unit 211, the S1 unit 222, the M1 unit 223, the N1 unit 224, the D1 unit 225, and the D2 unit 226. The scalar datapath side A115 includes the global scalar register file (RF) 211, the L1 / S1 local register file 212, the M1 / N1 local register file 213, and the D1 / D2 local register file 214. The vector datapath side B116 includes the L2 unit 241, the S2 unit 242, the M2 unit 243, the N2 unit 244, the C unit 245, and the P unit 246. The vector datapath side B116 includes the global vector register file 231, the L2 / S2 local register file 232, the M2 / N2 / C local register file 233, and the predicate register file 214. Which register file a functional unit can read from or write to is described in more detail herein.

[0073] The scalar datapath side, A115, includes the L1 unit 221. The L1 unit 221 typically accepts two 64-bit operands and produces a 64-bit result. Both operands are called from instruction-specified registers in the global scalar register file 211 or the L1 / S1 local register file 212. The L1 unit 221 performs the following operations selected by the instruction: 64-bit addition / subtraction operations; 32-bit minimum / maximum operations; 8-bit single instruction multiple data (SIMD) instructions (such as absolute value sum, minimum and maximum determination); rotated minimum / maximum operations; and various move operations between register files. The result is written to the instruction-specified register in the global scalar register file 211, the L1 / S1 local register file 212, the M1 / N1 local register file 213, or the D1 / D2 local register file 214.

[0074] The scalar datapath side A115 includes an S1 unit 222. The S1 unit 222 typically accepts two 64-bit operands and produces a 64-bit result. Both operands are called from instruction-specified registers in the global scalar register file 211 or the L1 / S1 local register file 212. In this example, the S1 unit 222 performs the same type of operations as the L1 unit 211. In other examples, there may be slight variations between the data processing operations supported by the L1 unit 211 and the S1 unit 222. The result is written to an instruction-specified register in the global scalar register file 211, the L1 / S1 local register file 212, the M1 / N1 local register file 213, or the D1 / D2 local register file 214.

[0075] The scalar datapath side A115 includes the M1 unit 223. The M1 unit 223 typically accepts two 64-bit operands and produces a 64-bit result. Both operands are called from instruction-specified registers in the global scalar register file 211 or the M1 / N1 local register file 213. Examples of instruction-selected operations performed by the M1 unit 223 include: 8-bit, 16-bit, and 32-bit multiplication operations, Galois field multiplication, complex multiplication with or without rounding, IEEE floating-point multiplication operations, complex dot product operations, 32-bit count operations, complex conjugate multiplication operations, and bitwise logical operations, shifts, additions, and subtractions. The result is written to the instruction-specified register in the global scalar register file 211, the L1 / S1 local register file 212, the M1 / N1 local register file 213, or the D1 / D2 local register file 214.

[0076] The scalar datapath side A115 includes the N1 unit 224. The N1 unit 224 typically accepts two 64-bit operands and produces a 64-bit result. Both operands are called from instruction-specified registers in the global scalar register file 211 or the M1 / N1 local register file 213. In this example, the N1 unit 224 performs the same type of operation as the M1 unit 223. Dual operations (called dual-issue instructions) also exist that utilize both the M1 unit 223 and the N1 unit 224. The result is written to the instruction-specified register in the global scalar register file 211, the L1 / S1 local register file 212, the M1 / N1 local register file 213, or the D1 / D2 local register file 214.

[0077] Scalar datapath side A 115 includes a D1 unit 225 and a D2 unit 226. Both D1 unit 225 and D2 unit 226 typically accept two 64-bit operands and produce a 64-bit result. D1 unit 225 and D2 unit 226 typically perform address calculations and corresponding load and store operations. D1 unit 225 is used for 64-bit scalar loads and stores, while D2 unit 226 is used for 512-bit vector loads and stores. In this example, D1 unit 225 and D2 unit 226 also perform: swapping, packing, and unpacking of load and store data; 64-bit SIMD arithmetic operations; and 64-bit bitwise logical operations. The D1 / D2 local register file 214 stores the base address and offset address used for address calculations for corresponding loads and stores. Both operands are retrieved from instruction-specified registers in the global scalar register file 211 or the D1 / D2 local register file 214. The calculated result is written into a register specified by the instruction in the global scalar register file 211 , the L1 / S1 local register file 212 , the M1 / N1 local register file 213 , or the D1 / D2 local register file 214 .

[0078] The vector datapath side B116 includes an L2 unit 241. The L2 unit 241 typically accepts two 512-bit operands and produces a 512-bit result. Both operands are called from instruction-specified registers in the global vector register file 231, the L2 / S2 local register file 232, or the predicate register file 234. In this example, the L2 unit 241 executes instructions similar to the L1 unit 221, except for wider 512-bit data. The result can be written to an instruction-specified register in the global vector register file 231, the L2 / S2 local register file 232, the M2 / N2 / C local register file 233, or the predicate register file 234.

[0079] The vector datapath side B116 includes an S2 unit 242. The S2 unit 242 typically accepts two 512-bit operands and produces a 512-bit result. Both operands are called from instruction-specified registers in the global vector register file 231, the L2 / S2 local register file 232, or the predicate register file 234. In this example, the S2 unit 242 executes instructions similarly to the S1 unit 222. The result is written to the instruction-specified register in the global vector register file 231, the L2 / S2 local register file 232, the M2 / N2 / C local register file 233, or the predicate register file 234.

[0080] The vector datapath side B116 includes an M2 unit 243. The M2 unit 243 typically accepts two 512-bit operands and produces a 512-bit result. Both operands are called from instruction-specified registers in the global vector register file 231 or the M2 / N2 / C local register file 233. In this example, the M2 unit 243 executes instructions similar to the M1 unit 222, except for wider 512-bit data. The result is written to the instruction-specified register in the global vector register file 231, the L2 / S2 local register file 232, or the M2 / N2 / C local register file 233.

[0081] The vector datapath side B116 includes an N2 unit 244. The N2 unit 244 typically accepts two 512-bit operands and produces a 512-bit result. Both operands are called from instruction-specified registers in the global vector register file 231 or the M2 / N2 / C local register file 233. In this example, the N2 unit 244 executes the same type of instruction as the M2 unit 243. There are also dual operations (called dual-issue instructions) that utilize both the M2 unit 243 and the N2 unit 244. The result is written to the instruction-specified register in the global vector register file 231, the L2 / S2 local register file 232, or the M2 / N2 / C local register file 233.

[0082] The vector datapath side B116 includes a correlation (C) unit 245. The C unit 245 typically accepts two 512-bit operands and produces a 512-bit result. Both operands are called from instruction-specified registers in the global vector register file 231 or the M2 / N2 / C local register file 233. In this example, the C unit 245 executes "Search" and "Search" instructions, which are used for WCDMA (Wideband Code Division Multiple Access) encoding / decoding. In this example, the C unit 245 can perform up to 512 times per clock cycle a 2-bit PN (pseudo-random number) and 8-bit I / Q (complex number); 8-bit and 16-bit sum of absolute differences (SAD) calculations, up to 512 SADs per clock cycle; horizontal addition and horizontal min / max instructions; and vector permute instructions. The C unit 245 also includes four vector control registers (CUCR0 through CUCR3) used to control certain operations of the C unit 245 instructions. Control registers CUCR0 through CUCR3 serve as operands for certain C unit 245 operations. In this example, control registers CUCR0 to CUCR3 are used to control the general permutation instruction (VPERM) and are used as masks for SIMD multiple dot product operations (DOTPM) and SIMD multiple sum of absolute differences (SAD) operations. In other examples, control register CUCR0 is used to store the polynomial for the Galois field multiplication operation (GFMPY), and control register CUCR1 is used to store the Galois field polynomial generator function.

[0083] The vector datapath side B116 includes a P unit 246. The vector predicate (P) unit 246 performs basic logic operations on registers in the local predicate register file 234. The P unit 246 has direct access to read from and write to the predicate register file 234. The logic operations include single-register unary operations such as: NEG (negation), which inverts each bit of a single register; BITCNT (bit count), which returns a count of the number of bits in a single register with a predetermined digital state (1 or 0); RMBD (rightmost bit detect), which returns the number of bit positions from the least significant bit position (rightmost) to the first bit position with a predetermined digital state (1 or 0); DECIMATE, which selects the Nth (1st, 2nd, 4th, etc.) bit to be output per instruction specification; and EXPAND, which repeats each bit N times (2, 4, etc.) specified by the instruction. The logic operations also include two-register binary operations such as AND, which takes the bitwise AND of the data of two registers; NAND, which takes the bitwise AND and NOT of the data of two registers; OR, which takes the bitwise OR of the data of two registers; NOR, which takes the bitwise OR and NOT of the data of two registers; and XOR, which takes the exclusive OR of the data of two registers. The logic operations include transferring data from a predicate register in the predicate register file 234 to another specified predicate register or to a specified data register in the global vector register file 231. One purpose of the P unit 246 is to control the manipulation of SIMD vector compare results for further SIMD vector operations. The BITCNT instruction can be used to count the number of "1"s in the predicate register to determine the number of valid data elements from the predicate register.

[0084] Figure 3 The global scalar register file 211 is described. There are 16 independent 64-bit wide scalar registers, labeled A0-A15. Each register of the global scalar register file 211 can be read from or written to as 64-bit scalar data. All scalar datapath-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can read from or write to the global scalar register file 211. The global scalar register file 211 can be read as 32 bits or read as 64 bits and written as 64 bits. The execution of the instruction determines the size of the read data. The vector datapath-side B116 functional units (L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246) can read from the global scalar register file 211 via the crossbar path 117, subject to the restrictions described below.

[0085] Figure 4The D1 / D2 local register file 214 is described. There are sixteen independent 64-bit wide scalar registers, labeled D0-D16. Each register of the D1 / D2 local register file 214 is read or written as 64-bit scalar data. All scalar datapath-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can write to the global scalar register file 211. Only the D1 unit 225 and D2 unit 226 can read from the D1 / D2 local register file 214. The data stored in the D1 / D2 local register file 214 may include base addresses and offset addresses used for address calculations.

[0086] Figure 5 The L1 / S1 local register file 212 is described. In this example, the L1 / S1 local register file 212 includes eight independent 64-bit wide scalar registers, labeled AL0-AL7. In this example, the instruction encoding allows the L1 / S1 local register file 212 to include up to 16 registers. In this example, eight registers are implemented to reduce circuit size and complexity. Each register of the L1 / S1 local register file 212 can be read from or written to as 64-bit scalar data. All scalar datapath-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can write to the L1 / S1 local register file 212. The L1 unit 221 and S1 unit 222 can read from the L1 / S1 local register file 212.

[0087] Figure 6 The M1 / N1 local register file 213 is described. In this example, eight independent 64-bit wide scalar registers are implemented, labeled AM0-AM7. In this example, the instruction encoding allows the M1 / N1 local register file 213 to include up to 16 registers. In this example, eight registers are implemented to reduce circuit size and complexity. Each register of the M1 / N1 local register file 213 can be read from or written to as 64-bit scalar data. All scalar datapath-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can write to the M1 / N1 local register file 213. The M1 unit 223 and N1 unit 224 can read from the M1 / N1 local register file 213.

[0088] Figure 7The global vector register file 231 is described. There are sixteen independent 512-bit wide vector registers. Each register of the global vector register file 231 can be read from or written to as 64-bit scalar data, labeled B0-B15. The instruction type determines the data size. All vector datapath-side B116 functional units (L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246) can read from or write to the global vector register file 231. The scalar datapath-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can read from the global vector register file 231 via the crossbar path 117, subject to the restrictions described below.

[0089] Figure 8 The predicate (P) local register file 234 is described. Eight independent 64-bit wide registers are stored, labeled P0-P7. Each register of the P local register file 234 can be read from or written to as 64-bit scalar data. The vector datapath-side B116 functional units, L2 unit 241, S2 unit 242, C unit 244, and P unit 246, can write to the P local register file 234. The L2 unit 241, S2 unit 242, and P unit 246 can read from the P local register file 234. One purpose of the P local register file 234 is to write a one-bit SIMD vector compare result from the L2 unit 241, S2 unit 242, or C unit 244, manipulate the SIMD vector compare result by the P unit 246, and use the manipulated result to control further SIMD vector operations.

[0090] Figure 9 The L2 / S2 local register file 232 is described. In this example, eight independent 512-bit wide vector registers are implemented. The instruction encoding in this example allows the L2 / S2 local register file 232 to include up to sixteen registers. In this example, eight registers are implemented to reduce circuit size and complexity. Each register of the L2 / S2 local vector register file 232 can be read from or written to as 64-bit scalar data, labeled BL0-BL7. Each register of the L2 / S2 local vector register file 232 can be read from or written to as 512-bit vector data, labeled VBL0-VBL7. The instruction type determines the data size. All vector datapath-side B116 functional units (L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246) can write to the L2 / S2 local vector register file 232. The L2 unit 241 and S2 unit 242 can read from the L2 / S2 local vector register file 232.

[0091] Figure 10 The M2 / N2 / C local register file 233 is described. In this example, eight independent 512-bit wide vector registers are implemented. In this example, the instruction encoding allows the M2 / N2 / C local register file 233 to include up to sixteen registers. In this example, eight registers are implemented to reduce circuit size and complexity. Each register of the M2 / N2 / C local vector register file 233 can be read from or written to as 64-bit scalar data, labeled BM0-BM7. Each register of the M2 / N2 / C local vector register file 233 can be read from or written to as 512-bit vector data, labeled VML0-VML7. All vector datapath-side B116 functional units (L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246) can write to the M2 / N2 / C local vector register file 233. The M2 unit 243 , the N2 unit 244 , and the C unit 245 may read from the M2 / N2 / C local vector register file 233 .

[0092] The provision of a global register file accessible by all functional areas on one side and a local register file accessible by some functional units on one side is a design choice. In another example, different accessibility provisions can be made, such as adopting a class of register files corresponding to the global register file described herein.

[0093] Crosspath 117 allows limited data exchange between scalar datapath side A 115 and vector datapath side B 116. During each operation cycle, one 64-bit data word can be called from global scalar register file A 211 to serve as an operand for one or more functional units of vector datapath side B 116, and one 64-bit data word can be called from global vector register file 231 to serve as an operand for one or more functional units of scalar datapath side A 115. Any scalar datapath side A 115 functional unit (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can read a 64-bit operand from global vector register file 231. The 64-bit operand is the least significant bits of the 512-bit data in the register accessed by global vector register file 231. Multiple scalar datapath side A 115 functional units can use the same 64-bit crosspath data as an operand during the same operation cycle. However, in a single operation cycle, a single 64-bit operand is transferred from the vector datapath side B116 to the scalar datapath side A115. Any vector datapath side B116 (L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246) can read a 64-bit operand from the global scalar register file 211. If the corresponding instruction is a scalar instruction, the cross-path operand data is treated as a 64-bit operand. If the corresponding instruction is a vector instruction, the upper 448 bits of the operand are filled with zeros. Multiple vector datapath side B116 functional units can use the same 64-bit cross-path data as the operand during the same operation cycle. In one example, in any single operation cycle, a single 64-bit operand is transferred from the scalar datapath side A115 to the vector datapath side B116.

[0094] Stream Engine 125( Figure 1) transfers data under certain limited circumstances. The stream engine 125 controls two data streams. One stream consists of a sequence of elements of a specific type. Programs operating on these streams read the data sequentially and then operate on each element. Each stream has the following basic properties: the stream data has well-defined start and end times; the stream data has a fixed element size and type throughout the stream; and the stream data has a fixed sequence of elements. Once a stream is opened, the stream engine 125 performs the following operations: calculates addresses; extracts the defined data type from the L2 unified cache 130 (which may require cache services from higher-level memories, such as in the case of a cache miss in the L2); performs data type manipulations such as zero extension, sign extension, and data element shuffling / permutation (such as matrix transposition); and transfers data directly to the programmed data register file in the processor core 110. Therefore, the stream engine 125 is beneficial for real-time digital filtering operations on well-behaved data. The stream engine 125 extracts tasks from these memories, freeing up the corresponding processor, enabling other processing functions.

[0095] The stream engine 125 provides several benefits. For example, the stream engine 125 allows multi-dimensional memory access, increases the available bandwidth of the functional units, minimizes the number of cache miss stalls due to the stream buffer bypassing the L1D cache 123, and reduces the number of scalar operations required to maintain a loop. The stream engine 125 also manages address pointers and handles address generation instruction slots freed for other computations and address generation for the D1 unit 225 and the D2 unit 226.

[0096] Processor core 110 ( Figure 1 ) operates on the instruction pipeline. As described further below, instructions are extracted from fixed-length instruction packets. All instructions require the same number of pipeline stages for fetching and decoding, but require a different number of execution stages.

[0097] Figure 11 The following pipeline stages are illustrated: a program fetch stage 1110, a dispatch and decode stage 1120, and an execute stage 1130. The program fetch stage 1110 comprises three stages for all instructions. The dispatch and decode stage 1120 comprises three stages for all instructions. The execute stage 1130 comprises one to four stages, depending on the instruction.

[0098] The fetch phase 1110 includes a program address generation (PG) stage 1111, a program access (PA) stage 1112, and a program receive (PR) stage 1113. During the program address generation stage 1111, a program address is generated in the processor and a read request is sent to the memory controller of the L1I cache. During the program access stage 1112, the L1I cache processes the request, accesses the data in its memory, and sends a fetch packet to the processor boundary. During the program receive stage 1113, the processor registers the fetch packet.

[0099] Instructions are fetched in fetch packets consisting of sixteen 32-bit wide words. Figure 12 Sixteen instructions 1201-1216 of a single extract packet are illustrated. The extract packets are aligned on 512-bit (16-word) boundaries. This example uses a fixed 32-bit instruction length, which makes it easy for the decoder to align. Properly aligned instruction extracts can load multiple instructions into the parallel instruction decoder. When the predetermined instruction alignment is stored in a memory coupled to the fixed instruction packet extract (by aligning the extract packets on 512-bit boundaries), the predetermined instruction alignment can obtain such properly aligned instruction extracts. In contrast, variable-length instructions require an initial step of locating each instruction boundary before decoding. Fixed-length instruction sets typically allow for a more regular layout of instruction fields, which simplifies the structure of each decoder and is beneficial to wide-issue VLIW processors.

[0100] The execution of individual instructions is partially controlled by the p bit in each instruction. In this example, the p bit is bit 0 of the 32-bit wide gap. The p bit determines whether the instruction is executed in parallel with the next instruction. In this example, instructions are scanned from lower to higher addresses. If the p bit of an instruction is 1, the next following instruction (higher memory address) is executed in parallel with the instruction (in the same cycle as the instruction). If the p bit of an instruction is 0, the next following instruction is executed in the cycle after the instruction.

[0101] Processor core 110 ( Figure 1 ) and L1I cache 121 pipeline ( Figure 1 ) are decoupled from each other. A fetch packet returned from the L1I cache may take different numbers of clock cycles, depending on external conditions, such as whether it hits in the L1I cache 121 or in the L2 combined cache 130. Thus, the program access stage 1112 may take several clock cycles instead of one clock cycle as in other stages.

[0102] Instructions executed in parallel form an execution packet. In this example, an execution packet can include up to sixteen 32-bit wide gaps for sixteen instructions. No two instructions in an execution packet can use the same functional unit. A gap is one of the following five types: 1) a self-sustaining instruction executed on one of the functional units of the processor core 110 (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, D2 unit 226, L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246); 2) a unitless instruction, such as a NOP (no operation) instruction or multiple NOP instructions; 3) a branch instruction; 4) a constant field extension; and 5) a condition code extension. Some of these gap types are further explained herein.

[0103] Dispatch and decode phase 1120 ( Figure 11 ) includes an instruction dispatch to the appropriate execution unit (DS) stage 1121; an instruction pre-decode (DC1) stage 1122; and an instruction decode and operand fetch (DC2) stage 1222. During the instruction dispatch to the appropriate execution unit stage 1121, fetch packets are divided into execute packets and assigned to the appropriate functional units. During the instruction pre-decode stage 1122, the source registers, destination registers, and associated paths are decoded for executing the instruction in the functional unit. During the instruction decode and operand fetch stage 1223, more detailed unit decoding is performed, and operands are read from the register file.

[0104] The execution phase 1130 includes execution (E1-E5) stages 1131-1135. Different types of instructions require different numbers of these stages to complete execution. These execution stages of the pipeline play an important role in understanding the device state at the processor cycle boundary.

[0105] During the E1 stage 1131, the instruction's conditions are evaluated and the operands are operated on. Figure 11 As illustrated, the E1 stage 1131 can receive operands from one of the stream buffers 1141 and the register file (illustratively shown as 1142). For load and store instructions, address generation is performed and address modifications are written to the register file. For branch instructions, the branch fetch packet in the PG stage is affected. Figure 11 As illustrated, load and store instructions access memory (illustrated here as memory 1151). For single-cycle instructions, when any condition of the instruction is evaluated as true, the result is written to the destination register file. If the condition is evaluated as false, the instruction does not write any result or has any pipeline operation after E1 stage 1131.

[0106] During E2 stage 1132, load instructions send the address to memory. Store instructions send the address and data to memory. Single-cycle instructions that saturate the result set the SAT bit in the control status register (CSR) if saturation occurs. For 2-cycle instructions, the result is written to the destination register file.

[0107] Data memory accesses are performed during the E3 stage 1133. Any multi-instruction that saturates the result sets the SAT bit in the control status register (CSR) if saturation occurs. For 3-cycle instructions, the result is written to the destination register file.

[0108] Load instructions bring data across the processor boundary during the E4 stage 1134. For 4-cycle instructions, the result is written to the destination register file.

[0109] During E5 level 1135, as in Figure 11 As illustrated in , a load instruction writes data into a register via input from memory 1151 to E5 stage 1135 .

[0110] Figure 13 An example of an instruction encoding 1300 used by processing unit core 110 is illustrated. The illustrated instruction format is suitable for arithmetic instructions from two sources. Other instruction encodings may also be used. Typically, each instruction comprises 32 bits and controls the operation of one of the controllable functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, D2 unit 226, L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246).

[0111] exist Figure 13 In the example shown in FIG1 , dst field 1301 specifies a register in the corresponding register file as the destination for the instruction result. src2 / cst field 1302 has several meanings, depending on the instruction opcode field 1304 and unit field 1305. One meaning specifies a register in the corresponding register file as the second operand. Another meaning is an immediate constant. Depending on the instruction type, field 1302 is treated as either an unsigned integer and zero-extended to the specified data length, or as a signed integer and sign-extended to the specified data length.

[0112] The src1 field 1303 specifies a register in the corresponding register file as the first source operand. The opcode field 1304 specifies the type of instruction. The unit field 1305, in conjunction with the side bit 1306, indicates which functional unit is used to execute the instruction. A detailed explanation of the opcode is beyond the scope of this description, except for the instruction options described below.

[0113] The s bit 1306 specifies either the scalar datapath side A 115 or the vector datapath side B 116. If s=0, the scalar datapath side A 115 is selected, which limits the functional unit to Figure 2 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, D2 unit 226 and corresponding register files are illustrated in FIG. Similarly, s=1 selects vector datapath side B116, which restricts the functional units to Figure 2 1 and 2. The L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, P unit 246 and corresponding register files are illustrated in FIG.

[0114] The p bit 1307 marks an execution packet. The p bit determines whether the instruction is executed in parallel with the following instruction. The p bit is scanned from lower to higher addresses. If p = 1 for the current instruction, the next instruction is executed in parallel with the current instruction. If p = 0 for the current instruction, the next instruction is executed in the cycle after the current instruction. All instructions executed in parallel constitute an execution packet. An execution packet can contain up to sixteen instructions. Each instruction in the execution packet uses a different functional unit.

[0115] Most instructions of the processing unit core 110 do not include direct encoding for conditional execution. However, instructions can be made conditional. The action of making an instruction conditional is called a predication, and the register storing the condition is called a predicate register. An execution packet may include two 32-bit condition code extension gaps that encode 4 bits of condition information for the instructions in the same execution packet. In this article, these condition code gaps are referred to as condition code extension gap 0 and condition code extension gap 1, and the 4 bits of condition information are referred to as the creg / z field.

[0116] Table 1 shows the encoding of the creg / z field. The creg bit identifies the predicate register and the z bit indicates whether the predicate is based on a zero or non-zero in the predicate register. The execution of conditional instructions depends on the value stored in the specified data register. If z=1, the test is for zero, and if z=0, the test is for non-zero. The case where creg=0 and z=0 is considered true to allow unconditional instruction execution. Note that the "z" in the z bit column refers to the zero / non-zero compare select mentioned above and "x" is the don't care state.

[0117]

[0118] Table 1

[0119] Figure 14Illustrates the encoding for condition code extension gap 0 1400. Field 1401 specifies the four creg / z bits allocated to instructions of the L1 unit 221, field 1402 specifies the four creg / z bits allocated to instructions of the L2 unit 241, field 1403 specifies the four creg / z bits allocated to instructions of the S1 unit 222, field 1404 specifies the four creg / z bits allocated to instructions of the S2 unit 242, field 1405 specifies the four creg / z bits allocated to instructions of the D1 unit 225, field 1406 specifies the four creg / z bits allocated to instructions of the D2 unit 226, field 1407 is unused / reserved, and field 1408 is encoded as a unique set of bits (CCEX0) to identify condition code extension gap 0. When this unique ID of condition code extension gap 0 is detected, the creg / z bit is used to control the conditional execution of any corresponding L1 unit 221, L2 unit 241, S1 unit 222, S2 unit 242, D1 unit 225, D2 unit 226 instructions in the same execution packet. Note that a properly encoded condition code extension gap 0 can make some instructions in the execution packet conditional and some instructions unconditional.

[0120] Figure 15 The encoding for condition code extension gap 1 1501 is illustrated. Field 1501 specifies the four creg / z bits assigned to instructions in the M1 unit 223, field 1502 specifies the four creg / z bits assigned to instructions in the M2 unit 243, field 1503 specifies the four creg / z bits assigned to instructions in the C unit 245, field 1504 specifies the four creg / z bits assigned to instructions in the N1 unit 224, field 1505 specifies the four creg / z bits assigned to instructions in the N2 unit 244, field 1506 is unused / reserved, and field 1507 is encoded as a unique set of bits (CCEX1) identifying condition code extension gap 1. When this unique ID for condition code extension gap 1 is detected, the corresponding creg / z bits are used to control the conditional execution of any M1 unit 223, M2 unit 243, C unit 245, N1 unit 224, and N2 unit 244 instructions in the same execution packet.

[0121] Reference again Figure 13 In some instructions, a bit called the constant extension bit may be encoded in the opcode field 1304 to indicate that the constant in the src2 / CST field 1302 is to be extended. The execution packet may include two 32-bit constant extension slots, each of which may store 27 bits that are concatenated with the 5-bit constant in field 1302 as high-order bits to form a 32-bit constant. Figure 16The fields of Constant Extension Slot 0 1600 are illustrated. Field 1601 stores the 27 most significant bits of an extended 32-bit constant. Field 1602 encodes a set of unique bits (CSTX0) to identify Constant Extension Slot 0. In this example, Constant Extension Slot 0 1600 can be used to extend a constant in one of an L1 unit 221 instruction, a D1 unit 225 instruction, an S2 unit 242 instruction, a D2 unit 226 instruction, an M2 unit 243 instruction, an N2 unit 244 instruction, a branch instruction, or a C unit 245 instruction within the same execution packet. Constant Extension Slot 1 is similar to Constant Extension Slot 0, except that a unique set of bits (CSTX1) is used to encode the gap to identify Constant Extension Slot 1. In this example, constant extension gap 1 can be used to extend a constant in one of an L2 unit 241 instruction, data in a D2 unit 226 instruction, an S1 unit 222 instruction, an offset in a D1 unit 225 instruction, an M1 unit 223 instruction, or an N1 unit 224 instruction in the same execution packet.

[0122] Constant extension gap 0 and constant extension gap 1 are used as follows. The instruction decoder 113 determines the constant in field 1302, referred to as the direct field, based on the instruction opcode bits, and determines whether the constant is to be extended using the previously mentioned constant extension bit in the opcode field 130. If the instruction decoder 113 detects constant extension gap 0 or constant extension gap 1, the instruction decoder 113 checks the instructions within the execution packet for the instruction corresponding to the detected constant extension gap. If a corresponding instruction has a constant extension bit equal to 1, constant extension is performed.

[0123] Figure 17 is a partial block diagram 1700 illustrating constant expansion. Figure 17 Assume that the instruction decoder 113 ( Figure 1) detects a constant extension gap and a corresponding instruction in the same execution packet. Instruction decoder 113 supplies the twenty-seven extension bits from field 1601 of the constant extension gap and the five constant bits from field 1302 of the corresponding instruction to concatenator 1701. Concatenator 1701 forms a single 32-bit word from these two parts. In this example, the twenty-seven extension bits from field 1601 of the constant extension gap are the most significant bits, and the five constant bits from field 1302 are the least significant bits. The combined 32-bit word is supplied to one input of multiplexer 1702. The five constant bits from the corresponding instruction field 1302 supply the second input to multiplexer 1702. The selection of multiplexer 1702 is controlled by the state of the constant extension bit. If the constant extension bit is 1, multiplexer 1702 selects the concatenated 32-bit input. If the constant extension bit is 0, then multiplexer 1702 selects the five constant bits from the corresponding instruction field 1302. The output of multiplexer 1702 supplies the input of sign extension unit 1703.

[0124] Sign extension unit 1703 forms the final operand value based on the input from multiplexer 1703. Sign extension unit 1703 receives control inputs scalar / vector and data size. The scalar / vector input indicates whether the corresponding instruction is a scalar or vector instruction. The functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) on datapath side A 115 execute scalar instructions. Any instruction directed to one of these functional units is a scalar instruction. The functional units L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, and C unit 245 on datapath side B 116 can execute either scalar or vector instructions. The instruction decoder 113 determines whether the instruction is a scalar or vector instruction based on the opcode bits. The P unit 246 can execute scalar instructions. The data size can be eight bits (byte B), sixteen bits (halfword H), 32 bits (word W), or 64 bits (doubleword D).

[0125] Table 2 lists the operation of the sign extension unit 1703 for various options.

[0126]

[0127]

[0128] Table 2

[0129] As above combined Figure 13As described, both constant extension gap 0 and constant extension gap 1 may include p bits to define an execution packet. In this example, as in the case of a conditional code extension gap, constant extension gap 0 and constant extension gap 1 have bit 0 (p bits) encoded as 1. Therefore, neither constant extension gap 0 nor constant extension gap 1 may be in the last instruction gap of an execution packet.

[0130] Technically, an execution packet may include a constant extension slot 0 or 1 and more than one corresponding instruction marked as constant extension (e bit = 1). For this case, for constant extension slot 0, more than one of the L1 unit 221 instruction, the data in the D1 unit 225 instruction, the S2 unit 242 instruction, the offset in the D2 unit 226 instruction, the M2 unit 243 instruction, or the N2 unit 244 instruction in the execution packet may have an e bit of 1. For this case, for constant extension slot 1, more than one of the L2 unit 241 instruction, the data in the D2 unit 226 instruction, the S1 unit 222 instruction, the offset in the D1 unit 225 instruction, the M1 unit 223 instruction, or the N1 unit 224 instruction in the execution packet may have an e bit of 1. In one example, the instruction decoder 113 determines that this case is an invalid operation and is not supported. Alternatively, this combination may be supported by the extension bit applied to the constant extension slot of each corresponding functional unit instruction marked as constant extension.

[0131] The L1 unit 221, S1 unit 222, L2 unit 241, S2 unit 242, and C unit 245 typically operate in a single instruction multiple data (SIMD) mode. In this SIMD mode, the same instruction is applied to packed data from two operands. Each operand holds multiple data elements arranged in predetermined intervals. SIMD operations are enabled by carry control at data boundaries. This carry control enables operations on varying data widths.

[0132] Figure 18The carry control logic is described below. AND gate 1801 receives the carry output of bit N within the arithmetic logic unit of the operand width (64 bits for the scalar datapath side A115 functional unit and 512 bits for the vector datapath side B116 functional unit). AND gate 1801 also receives a carry control signal, which is explained further below. The output of AND gate 1801 is supplied to the carry input of bit N+1 of the arithmetic logic unit of the operand width. AND gates (such as AND gate 1801) are set between each pair of bits at possible data boundaries. For example, for 8-bit data, such AND gates would be between bits 7 and 8, bits 15 and 16, bits 23 and 24, and so on. Each such AND gate receives a corresponding carry control signal. If the data size is the minimum size, each carry control signal is 0, effectively blocking carry propagation between adjacent bits. If the selected data size requires two arithmetic logic unit segments, the corresponding carry control signal is 1. Table 3 below shows example carry control signals for a 512-bit wide operand, as used by the vector datapath side B116 functional unit, which can be divided into 8-bit segments, 16-bit segments, 62-bit segments, 64-bit segments, 128-bit segments, or 256-bit segments. In Table 3, the upper 32 bits control the carry of the upper bits (bits 128 to 511), and the lower 32 bits control the carry of the lower bits (bits 0 to 127). There is no need to control the carry output of the most significant bit, so only 63 carry control signals are required.

[0133]

[0134] Table 3

[0135] Commonly used integer powers of 2 (2 N However, the carry control technique is not limited to integer powers of 2 and can be applied to other data sizes or operand widths.

[0136] In this example, at least the L2 unit 241 and the S2 unit 242 use two types of SIMD instructions using registers in the predicate register file 234. In this example, all of these SIMD vector predicate instructions operate on the data size specified by the instruction. The data size includes byte (8-bit) data, halfword (16-bit) data, word (32-bit) data, doubleword (64-bit) data, quadword (128-bit) data, and half-vector (256-bit) data. In the first type of these instruction types, the functional unit (L2 unit 241 or S2 unit 242) performs a SIMD comparison on the packed data in two general data registers and supplies the result to the predicate data register. The instruction specifies the data size, two general data register operands, and the destination predicate register. In this example, each predicate data register includes a bit corresponding to each minimum data size portion of the general data register. In the current example, the general data register is 512 bits (64 bytes) and the predicate data register is 64 bits (8 bytes). Each bit of the predicate data register corresponds to eight bits of the general data register. Performs a comparison on a specified data size (8, 16, 32, 64, 128, or 256 bits). If the comparison is true, the functional unit supplies "1" to all asserted register bits corresponding to that portion of the data size. If the comparison is false, the functional unit supplies zero to the asserted register bits corresponding to that portion of the data size. In this example, the enabled comparison operations include "less than," "greater than," and "equal to."

[0137] In a second type of instruction type, a functional unit (L2 unit 241 or S2 unit 242) performs a first SIMD operation or a second SIMD operation on packed data in a general data register based on the data state in the predicate data register. The instruction specifies a data size, one or two general data register operands, a control predicate register, and a general data register destination. For example, the functional unit may select a first data element of the first operand or a second data element of the second operand for each data size portion of two vector operands to be stored in the destination register, with this selection depending on the 1 / 0 state of the corresponding bit in the predicate data register. In another example, the data element of the signal vector operand may be saved to memory or not, depending on the data of the corresponding bit of the predicate memory.

[0138] The operation of the P-unit 245 allows for various complex vector SIMD operations based on more than one vector comparison. For example, two comparisons can be used for range determination. In a SIMD operation, a candidate vector is compared to a vector reference having the minimum value of a range packed within a data register. The "greater than" result is a scalar data value with the bit corresponding to the SIMD data width set to 0 or 1, depending on the SIMD comparison, and is stored in a predicate data register. Another SIMD comparison of the candidate vector with another reference vector having the maximum value of a range packed within another data register is performed, producing another scalar value, whose "less than" result is stored in another predicate register. The P-unit then ANDs the two predicate registers. The AND result indicates whether each SIMD data portion of the candidate vector is in or out of range. The P-unit BITCNT instruction ANDing the result can generate a count of data elements within the comparison range. The P-unit ENG function can be used to convert a less than comparison result into a greater than or equal to comparison result, a greater than comparison result into a less than or equal to comparison result, or an equal to comparison result into a not equal to comparison result.

[0139] Stream Engine

[0140] Figure 19 illustrate Figure 1 1. A conceptual view of the stream engine 125 of an example processor 100. Figure 19 The processing of a single stream representing two streams controlled by stream engine 125 is illustrated. Stream engine 1900 includes a stream address generator 1901. Stream address generator 1901 continuously generates addresses for stream elements and supplies these element addresses to system memory 1910. Memory 1910 retrieves the data (data elements) stored at the element addresses and supplies these data elements to a data first-in, first-out (FIFO) buffer 1902. Data FIFO buffer 1902 provides buffering between memory 1910 and processor 1920. Data formatter 1903 receives data elements from data FIFO memory 1902 and provides data formatting according to the stream definition. This processing is described in more detail herein. Stream engine 1900 supplies the formatted data elements from data formatter 1903 to processor 1920. Programs executed on processor 1920 consume the data and generate output.

[0141] Stream elements typically reside in system memory. Memory does not dictate a particular structure for a stream. A program defines a stream and therefore dictates its structure by specifying stream attributes, such as the address of the first element of the stream, the size and type of elements in the stream, the formatting of the data in the stream, and the sequence of addresses associated with the stream.

[0142] The stream engine defines the address sequence of the elements of a stream based on pointers that traverse the entire memory. Multiple levels of nested loops control the paths taken by the pointers. The iteration count of a loop level indicates the number of times that level is repeated. The dimension gives the distance between the pointer positions of that loop level.

[0143] In the basic forward flow, when the implicit dimension of the innermost loop is one element, the innermost loop physically consumes consecutive elements from the memory. The pointer moves element by element in a continuously increasing order. In each level outside the inner loop, the loop moves the pointer to a new position based on the size of the dimension of the loop level. This form of addressing allows the program to specify a regular path through the memory using a small number of parameters. Table 4 lists the addressing parameters of the basic flow. In this example, the range of ELEM_BYTES is from 1 to 64 bytes, as shown in Table 5.

[0144]

[0145] Table 4

[0146]

[0147]

[0148] Table 5

[0149] The above definition maps successive elements of the stream to increasing addresses in memory, which is suitable for many algorithms. Some algorithms are better served by reading elements at decreasing memory addresses or in reverse stream addressing. For example, discrete convolution computes the vector dot product, which is given by:

[0150]

[0151] where f[] and g[] represent arrays in memory. For each output, the algorithm reads f[] in the forward direction and g[] in the reverse direction. The actual filter restricts the index range of [x] and [tx] to a finite number of elements. To support this pattern, the stream engine supports reading elements in descending address order.

[0152] Matrix multiplication operations present unique challenges for the streaming engine. Each element in a matrix product is the vector dot product between a row from the first matrix and a column from the second matrix. Programs typically store matrices in either row-major or column-major order. Row-major order stores all elements of a single row contiguously in memory. Column-major order stores all elements of a single column contiguously in memory. Matrices are typically stored in the same order as the language's default array order. As a result, only one of the two matrices in a matrix multiplication operation maps to a 2-dimensional stream definition in the streaming engine. In a typical example, indexing steps through columns on one array and rows on the other. The streaming engine supports implicit matrix transposition with transposed streams. Transposed streams avoid the cost of explicitly transforming data in memory. Instead of accessing data in strictly contiguous element order, the streaming engine effectively swaps the inner two loop dimensions in transverse order, extracting elements into contiguous vector lanes along the second dimension.

[0153] This algorithm works, but it is impractical to implement for small element sizes. Some algorithms work on matrices where multiple columns and rows are concatenated together. Therefore, the streaming engine defines a separate transpose granularity. The hardware dictates the smallest granularity. The transpose granularity needs to be at least as large as the element size. The transpose granularity causes the streaming engine to extract one or more consecutive elements from dimension 0 before moving along dimension 1. When the granularity is equal to the element size, a single column is extracted from the row-major array. Otherwise, the granularity specifies that two, four, or more columns are extracted from the row-major array at a time. This also applies to column-major layouts by swapping rows and columns in this description. The parameter GRANULE indicates the transpose granularity in bytes.

[0154] Another common matrix multiplication technique swaps the innermost two loops of the matrix multiplication. When reading across the rows of another matrix, the generated inner loop no longer reads down the columns of one matrix. For example, the algorithm can lift an item outside the inner loop and replace it with a scalar value. The innermost loop can be implemented by performing a vector sum after a single scalar and vector multiplication. Alternatively, the scalar value can be copied over the entire length of the vector and multiplied by vector and vector. The stream engine of this example directly supports the latter case and related usage patterns with an element repeat mode. In this mode, the stream engine reads a particle / granule smaller than the full vector size and copies the particle to fill the next vector output.

[0155] The streaming engine treats each complex number as a single element with two sub-elements, which give the real and imaginary parts (Cartesian coordinates) or the magnitude and angle parts (polar coordinates) of the complex number. Not all programs or peripherals agree on the order in which these sub-elements should be present in memory. Therefore, the streaming engine provides the ability to costlessly interchange two sub-elements of a complex number. This feature interchanges half of an element without interpreting its contents and can be used to interchange pairs of sub-elements of any type, not just complex numbers.

[0156] Algorithms often prefer to operate with high precision, but high-precision values ​​require more storage and bandwidth than lower-precision values. Often, programs store data in memory at low precision, promote these values ​​to higher precision for calculations, and then reduce these values ​​to lower precision for storage. The stream engine directly supports this operation by allowing algorithms to specify a level of type promotion. In this example, each subelement can be promoted to a larger type size by sign-extending or zero-extending the integer type. In some examples, the stream engine supports floating-point promotion, which promotes 16-bit and 32-bit floating-point values ​​to 32-bit and 64-bit formats, respectively.

[0157] The stream engine defines a stream as a discrete sequence of data elements, which are then consumed by processing unit cores 110 in a continuous manner, packaged into vectors. Vectors are similar to streams because they contain multiple homogeneous elements and some implicit sequence. Because the stream engine reads streams, but processing unit cores 110 consume vectors, the stream engine maps streams to vectors in a consistent manner.

[0158] A vector consists of lanes of equal size, each containing sub-elements. Processing unit core 110 designates the rightmost lane of a vector as lane 0, regardless of the current endian mode. Lanes are numbered incrementally from right to left. The actual number of lanes within a vector varies depending on the length of the vector and the data size of the sub-elements.

[0159] Figure 20 The following illustrates the sequence of formatting operations performed by the formatter 1903. The formatter 1903 includes three sections: an input section 2010, a formatting section 2020, and an output section 2030. The input section 2010 receives data from the system memory 1910 accessed by the stream address generator 1901. This data can be implemented as a linear extraction stream 2011 or a transposed extraction stream 2012.

[0160] The formatting section 2020 includes various formatting blocks. The formatting performed by these blocks within the formatter 1903 is further described below. The complex number interchange block 2021 optionally interchanges two sub-elements that form a complex number element. The type promotion block 2022 optionally promotes each data element to a larger data size. Promotion includes zero extension for unsigned integers and sign extension for signed integers. The decimation block 2023 optionally decimates data elements. In this example, the decimation can be 2:1, i.e., retaining one every other data element, or 4:1, i.e., retaining one every four data elements. The element repetition block 2024 optionally repeats individual data elements. In this example, the data element repetition is an integer power of 2 (2 N , where N is an integer), including 2x, 4x, 8x, 16x, 32x, and 64x. In this example, data repetition can be extended across multiple destination vectors. Vector Length Mask / Group Repeat block 2025 has two main functions. An independently specified vector length VECLEN controls the data elements supplied to each output data vector. When group repeat is off, excess lanes in the output data vector are filled with zeros and marked as invalid. When group repeat is on, input data elements of the specified vector length are repeated to fill the output data vector.

[0161] The output section 2030 holds data for output to the corresponding functional unit. The registers and buffers for the processor 2031 store data to be processed by the processing unit core 110 ( Figure 1 )'s functional unit as a formatted data vector for operands.

[0162] Figure 21 An example of lane assignment in a vector is shown. Vector 2100 is divided into eight 64-bit lanes (8×64 bits = 512-bit vector length). Lane 0 includes bits 0 to 63, lane 1 includes bits 64 to 127, lane 2 includes bits 128 to 191, lane 3 includes bits 192 to 255, lane 4 includes bits 256 to 319, lane 5 includes bits 320 to 383, lane 6 includes bits 384 to 447, and lane 7 includes bits 448 to 511.

[0163] Figure 22Another example of lane assignment in a vector is illustrated: Vector 2210 is divided into sixteen 32-bit lanes (16×32 bits=512 bits of vector length). Channel 0 includes bits 0 to 31, channel 1 includes bits 32 to 63, channel 2 includes bits 64 to 95, channel 3 includes bits 96 to 127, channel 4 includes bits 128 to 159, channel 5 includes bits 160 to 191, channel 6 includes bits 192 to 223, channel 7 includes bits 224 to 255, channel 8 includes bits 256 to 287, channel 9 includes bits 288 to 319, channel 10 includes bits 320 to 351, channel 11 includes bits 352 to 383, channel 12 includes bits 384 to 415, channel 13 includes bits 416 to 447, channel 14 includes bits 448 to 479, and channel 15 includes bits 480 to 511.

[0164] The stream engine maps the innermost stream dimension directly to the vector lanes. The stream engine maps the first elements within the innermost stream dimension to lower lane numbers and the last elements to higher lane numbers, regardless of whether the stream advances in increasing or decreasing address order. Regardless of how the streams are ordered, the stream engine places the elements in the vector in increasing lane order. For non-compound data, the stream engine places the first element at the processing unit core 110 ( Figure 1 ) is placed in channel 0 of the vector extracted from the pair, the second element is placed in channel 1, and so on. For composite data, the streaming engine places the first element in channels 0 and 1, the second element in channels 2 and 3, and so on. The subelements within an element maintain the same relative order regardless of the streaming direction. For non-interchanged composite elements, the subelement with the lower address in each pair is placed in the even-numbered channel, and the subelement with the higher address in each pair is placed in the odd-numbered channel. For interchanged composite elements, the placement is reversed.

[0165] The stream engine fills each vector extracted by the CPU with as many elements as the processing unit core 110 can extract from the innermost stream dimension. If the innermost dimension is not a multiple of the vector length, the stream engine fills it with zeros to stretch that dimension to a multiple of the vector length. As described below, the stream engine marks these channels as invalid. Therefore, for higher-dimensional streams, the first element of each iteration from the outer dimensions arrives in channel 0 of the vector. The stream engine maps the innermost dimension to consecutive channels in the vector. For transposed streams, if the transposition swaps dimensions 1 and 0, the innermost dimension will contain groups of sub-elements along dimension 1 but not dimension 0, because the transposition swapped these two dimensions.

[0166] Two-dimensional (2D) streams exhibit greater diversity than one-dimensional streams. The basic 2D stream extracts smaller rectangles from a larger rectangle. The transposed 2D stream reads rectangles column by column rather than row by row. A recurrent stream, whose second dimension overlaps the first, performs a finite impulse response (FIR) filter tap, repeatedly looping over the FIR filtered samples to provide a sliding window of input samples.

[0167] Figure 23 This illustrates an area of ​​memory that can be accessed using a basic two-dimensional stream. The inner two dimensions represented by ELEM_BYTES, ICNT0, DIM1, and ICNT1 (see Table 4) provide sufficient flexibility to describe removing a smaller rectangle 2320 having dimensions 2321 and 2322 from a larger rectangle 2310 having dimensions 2311 and 2312. In this example, rectangle 2320 is a 9x13 rectangle of 64-bit values ​​and rectangle 2310 is a larger 11x19 rectangle. The following stream parameters define the stream: ICNT0 = 9, ELEM_BYTES = 8, ICNT1 = 13, DIM1 = 88 (11 times 8).

[0168] Therefore, the iteration count in dimension 0 2311 is nine, and the iteration count in dimension 1 2322 is thirteen. Note that ELEM_BYTES scales the innermost dimension. The first dimension has ICNT0 elements of size ELEM_BYTES. The stream address generator does not scale the outer dimensions. Therefore, DIM1 = 88, which is eleven elements, where each element is scaled by eight bytes.

[0169] Figure 24 illustrate Figure 23 The stream engine extracts the elements of the stream in the order shown as order 2400. The first nine elements are from the first row of matrix 2320, hop 1 to hop 8 from left to right. The 10th to 24th elements are from the second row, and so on. As the stream moves from the 9th element to the 10th element ( Figure 24 (For jumps in 9), the stream engine calculates the new position based on the position of the pointer at the beginning of the inner loop, rather than the position of the pointer at the end of the first dimension. Therefore, DIM1 is independent of ELEM_BYTES and ICNT0. DIM1 represents the distance between the first bytes of each consecutive row.

[0170] The transposed stream is accessed along dimension 1 before being accessed along dimension 0. The following examples illustrate transposed streams with varying transposition granularity. Figure 25 This illustrates extracting a smaller rectangle 2520 (12×8) having dimensions 2521 and 2522 from a larger rectangle 2510 (14×13) having dimensions 2511 and 2512. Figure 25ELEM_BYTES is equal to 2.

[0171] Figure 26 Explain how the stream engine extracts Figure 25 The example stream of has a four-byte transposed granularity. Extraction pattern 2600 extracts pairs of elements from each row (because a granularity of four is twice the ELEM_BYTES value of two), but in addition shifts down the columns. Once the stream engine reaches the bottom of a pair of columns, it repeats the pattern with the next pair of columns.

[0172] Figure 27 Explain how the stream engine extracts Figure 25 The example stream in FIG2700 has a transposed granularity of eight bytes. The overall structure remains the same. As shown in extraction pattern 2700, the stream engine extracts four elements from each row (because a granularity of eight is four times the ELEM_BYTES value of two), and then moves on to the next row in the column.

[0173] The streams examined so far read each element from memory exactly once. A stream may read a given element from memory multiple times, effectively looping over a portion of memory. FIR filters exhibit two common looping patterns: rereading the same filter tap for each output, and reading input samples from a sliding window. Two consecutive outputs require input from two overlapping windows.

[0174] Figure 28 illustrate Figure 1 Detail of the stream engine 125. The stream engine 125 comprises three main sections: stream 0 2810; stream 1 2820; and a shared L2 interface 2830. Both stream 0 2810 and stream 1 2820 contain the same hardware operating in parallel. Both stream 0 2810 and stream 1 2820 share the L2 interface 2830. Each stream 2810 and 2820 provides the processing unit core 110 with a rate of up to 512 bits per cycle ( Figure 1 ) data, which is enabled by dedicated flow paths and shared dual L2 interfaces.

[0175] Each stream engine 125 includes a corresponding dedicated 6-dimensional (6D) stream address generator 2811 / 2821, each of which can generate a new non-aligned request per cycle. As further described herein, the address generator 2811 / 2821 outputs a 512-bit aligned address that overlaps an element in the sequence defined by the stream parameters.

[0176] Each address generator 2811 / 2821 is connected to a corresponding dedicated micro-table lookaside buffer (μTLB) 2812 / 2822. The μTLB 2812 / 2822 converts a single 48-bit virtual address to a 44-bit physical address each cycle. Each μTLB 2812 / 2822 has 8 entries, covering a minimum of 32KB with 4KB pages or a maximum of 16MB with 2MB pages. Each address generator 2811 / 2811 generates two addresses per cycle. The μTLB 2812 / 2822 only translates one address per cycle. To maintain throughput, the stream engine 125 operates under the assumption that most stream references are within the same 4kB page. Therefore, address translation does not modify bits 0 through 11 of the address. If aout0 and aout1 are aligned in the same 4KB page (aout0[47:12] are the same as aout1[47:12]), the μTLB 2812 / 2822 translates only aout0 and reuses the translation of the higher bits of the two addresses.

[0177] The translated addresses are queued in the corresponding command queues 2813 / 2823. These addresses are aligned with the information from the corresponding corresponding store dispatch and tracking 2814 / 2824. The stream engine 125 does not explicitly manage the μTLB 2812 / 2822. The system memory management unit (MMU) invalidates the μTLB as needed during context switches.

[0178] Storage dispatch and tracking 2814 / 2824 manages the internal storage of the stream, explores data reuse, and tracks the lifespan of each piece of data. This block accepts two virtual addresses in each cycle and binds these addresses to gaps in the internal storage if the addresses are not already assigned to a gap. Data storage is organized as an array of gaps. The stream engine maintains the following metadata to track the content and lifespan of the data in each gap: a 49-bit virtual address associated with the gap, a valid bit indicating whether the tag address is valid, a ready bit indicating that data has arrived at the address, a valid bit indicating whether there are any outstanding data references, and a last reference value indicating the most recent reference to the gap in the reference queue. Storage dispatch and tracking are further described herein.

[0179] The corresponding reference queue 2815 / 2825 stores a sequence of references generated by the corresponding corresponding address generator 2811 / 2821. This sequence of references enables the data formatting network to present data to the processing unit core 110 in the correct order. Each entry in the corresponding reference queue 2815 / 2825 contains the necessary information for reading data from the data memory and aligning the data for the processing unit core 110. The corresponding reference queue 2815 / 2825 maintains the information listed in Table 6 in each slot:

[0180]

[0181] Table 6

[0182] When the address generator 2811 / 2821 generates a new address, the storage dispatch and tracking 2814 / 2824 inserts a reference into the reference queue 2815 / 2825. When data becomes available and there is space in the stream head register, the storage dispatch and tracking 2814 / 2824 removes the reference from the reference queue 2815 / 2825. When the storage dispatch and tracking 2814 / 2824 removes the gap reference from the reference queue 2815 / 2825 and formats the data, these references are checked against the most recent reference to the corresponding gap. The storage dispatch and tracking 2814 / 2824 compares the reference queue 2815 / 2825 with the pointer removed to the most recent reference recorded for the gap. If the pointer matches the most recent reference recorded, the storage dispatch and tracking 2814 / 2824 marks the gap as inactive once the data is no longer needed.

[0183] The stream engine 125 has a corresponding data store 2816 / 2826 for a selected number of elements. Deep buffering allows the stream engine to fetch ahead of the stream, thereby hiding memory system latency. Each data store 2816 / 2826 accommodates two simultaneous read operations and two simultaneous write operations per cycle, so each data store is referred to as a two-read-two-write (2r2w) data store. In other examples, the buffering amount can be different. In the current example, the stream engine 125 contributes 32 slots to each stream, each of which is tagged with the metadata described previously. Each slot holds 64 bytes of data in eight blocks of eight bytes.

[0184] The data storage 2816 / 2826 and the corresponding storage dispatch / tracking logic 2814 / 2824 and reference queue 2815 / 2825 implement the reference Figure 19 Data FIFO 1902 discussed.

[0185] The corresponding butterfly network 2817 / 2827 includes a formatter 1903 ( Figure 19 、 Figure 20). The butterfly network 2817 / 2827 receives 128 bytes of input and produces 64 bytes of output. The first level of the butterfly network is actually a half level that collects bytes from the two gaps that match the misaligned extraction and merges the collected bytes into a single rotated 64-byte array. The remaining six levels form a standard butterfly network. The corresponding butterfly network 2817 / 2827 performs the following operations: rotate the next element down to byte lane 0; promote data types by powers of two if requested; swap the real and imaginary parts of the complex number if requested; and convert big-endian to little-endian if the processing unit core 110 is currently in big-endian mode. The user specifies the element size, type promotion, and real / imaginary swap as part of the parameters of the stream.

[0186] The stream engine 125 attempts to extract and format the data ahead of the processing unit core 110's demand in order to maintain sufficient throughput. The corresponding stream head registers 2818 / 2828 provide a small amount of buffering so that the process remains sufficiently pipe-lined. The corresponding stream head registers 2818 / 2828 are not directly visible on the architecture. Each stream also has a corresponding stream valid register 2819 / 2829. The valid register 2819 / 2829 indicates which element in the corresponding stream head register 2818 / 2828 is valid.

[0187] The two flows 2810 / 2820 share a pair of independent L2 interfaces 2830: L2 interface A (IFA) 2833 and L2 interface B (IFB) 2834. For an aggregate bandwidth of 1024 bits / cycle, each L2 interface directly communicates with the L2 controller 130 ( Figure 1 ) provides a throughput of 512 bits / cycle. The L2 interface uses a credit-based Multicore Bus Architecture (MBA) protocol. The MBA protocol is described in more detail in U.S. Patent 9,904,645, entitled "Multicore Bus Architecture with Non-Blocking High Performance Transaction Credit System," which is incorporated herein by reference. The L2 controller allocates a pool of command credits to each interface. When reading L2RAM, L2 cache, and Multicore Shared Memory Controller (MSMC) memory (as described in more detail herein), this pool has enough credits to enable each interface to send enough requests to obtain sufficient read-return bandwidth.

[0188] To maximize performance, in this example, both flows can use both L2 interfaces, allowing a single flow to send a peak command rate of two requests per cycle. Each interface prefers one flow over the other, but this preference changes dynamically for each request. The IFA 2833 and IFB 2834 prefer opposite flows; when the IFA 2833 prefers flow 0, the IFB 2834 prefers flow 1, and vice versa.

[0189] The corresponding arbitrator 2831 / 2832 before each corresponding interface 2833 / 2834 applies the following basic protocol on each cycle with available credit. The arbitrator 2831 / 2832 checks whether the preferred stream has a command ready to send. If so, the arbitrator 2831 / 2832 selects the command. The arbitrator 2831 / 2832 next checks whether the alternative stream has at least two requests or one command ready to send and no credit. If so, the arbitrator 2831 / 2832 pulls the command from the alternative stream. If either interface issues a command, the preferred stream and the alternative stream are swapped for the next request. Using this algorithm, the two interfaces are able to dispatch requests as quickly as possible while maintaining fairness between the two streams. The first rule ensures that each stream can send a request on each cycle with available credit. The second rule provides a mechanism for the first stream to borrow the interface of the other stream when the second interface is idle. The third rule spreads the bandwidth requirements for each stream across the two interfaces, ensuring that neither interface becomes a bottleneck.

[0190] The corresponding coarse-grained rotators 2835 / 2836 enable the stream engine 125 to support the transposed matrix addressing mode. In this mode, the stream engine 125 swaps the two innermost dimensions of a multi-dimensional loop to access the array column-by-column rather than row-by-row. The corresponding rotators 2835 / 2836 are not architecturally visible.

[0191] Figure 29 An example flow template register 2900 is illustrated. A flow definition template provides the complete structure of a flow containing data. The iteration count and dimensions provide most of the structure, while various flags provide the remaining details. In this example, a single flow template 2900 is defined for all flows containing data. All flow types supported by the flow engine are covered by this template 2900. The flow engine supports six levels of loop nesting for addressing elements in the flow. Most fields in the flow template 2900 map directly to parameters in the algorithm. The numbers on the fields are the number of bits in the 256-bit vector. Table 7 shows the flow field definitions for the flow template.

[0192] Field Name Figure 29 Reference numerals in describe Size / number of digits ICNT0 2901 Iteration count for loop 0 32 ICNT1 2902 Iteration count for loop 1 32 ICNT2 2903 Iteration count for loop 2 32 ICNT3 2904 Iteration count for loop 3 32 ICNT4 2905 Iteration count for loop 4 32 ICNT5 2906 Iteration count for loop 5 32 DIM1 2911 Signed dimensions of loop 1 32 DIM2 2912 Signed dimensions of loop 2 32 DIM3 2913 Signed dimensions of loop 3 32 DIM4 2914 Loop 4 signed dimensions 32 DIM5 2915 Signed dimensions of loop 5 32 FLAGS 2921 Stream modifier flags 64

[0193] Table 7

[0194] Loop 0 is the innermost loop and loop 5 is the outermost loop. In the current example, DIM0 is equal to ELEM_BYTES, which physically defines continuous data. Therefore, stream template register 2900 does not define DIM0. The stream engine 125 interprets the iteration count as an unsigned integer and the dimensions as unscaled signed integers. An iteration count of zero at any level (ICNT0, ICNT1, ICNT2, ICNT3, ICNT4, or ICNT5) indicates an empty stream. Each iteration count must be at least one to define a valid stream. The above templates specify the type of element, the length of the stream, and the dimensions. The stream instructions each specify a starting address. For example, this is specified by a scalar register in the scalar register file 211 that stores the starting address. Therefore, a program can open multiple streams using the same template (but with different registers storing the starting address).

[0195] Figure 30 illustrate Figure 29 An example of subfield definition of the identification field 2911 is shown. Figure 30 As shown in FIG, the identification field 2911 is 6 bytes or 48 bits. Figure 30 Table 8 shows the definition of these fields.

[0196]

[0197] Table 8

[0198] The Element Type (ELTYPE) field 3001 defines the data type of the element in the stream. The encoding of the four bits of the ELTYPE field 3001 is defined as shown in Table 9.

[0199]

[0200]

[0201] Table 9

[0202] The real / complex type determines whether the stream engine treats each element as a real or complex number with two parts (real / imaginary or magnitude / angle), and also specifies whether the two parts of a complex number are interchanged. Complex types have a total element size that is twice the size of the sub-element. Otherwise, the sub-element size is equal to the total element size.

[0203] The sub-element size determines the type for the purpose of type promotion and vector channel width. For example, when a stream requests type promotion, a 16-bit sub-element is promoted to a 32-bit sub-element or a 64-bit sub-element. Since the core 110 lists vectors in little-endian byte order, when the processing unit core 110 ( Figure 1 )When operating in big-endian mode, vector lane width is important.

[0204] The total element size specifies the minimum granularity of the stream, which determines the number of bytes the stream extracts for each iteration of the innermost loop. The stream reads complete elements, either in increasing or decreasing order. Therefore, the innermost dimension of the stream spans ICNT0 × total element size bytes.

[0205] The "TRANSPOSE" field 3002 determines whether the stream engine accesses the stream in a transposed order. The transposed order swaps the two internal addressing levels. The TRANSPOSE field 3002 also indicates the granularity used to transpose the stream. The encoding of the three bits of the TRANSPOSE field 3002 is defined as shown in Table 10 for normal 2D operation.

[0206] Transpose meaning 000 Transpose Disable 001 Transpose on an 8-bit boundary 010 Transpose on a 16-bit boundary 011 Transpose on a 32-bit boundary 100 Transpose on a 64-bit boundary 101 Transpose on a 128-bit boundary 110 Transpose on a 256-bit boundary 111 reserve

[0207] Table 10

[0208] The stream engine 125 can actually transpose data elements at a granularity different from the element size, thus allowing the program to extract multiple columns of elements from each row. The transposition granularity cannot be smaller than the element size. The TRANSPOSE field 3002 interacts with the DIMFMT field 3009 in a manner further described below.

[0209] The "PROMOTE" field 3003 controls whether the stream engine promotes child elements in the stream and the type of promotion. When enabled, the stream engine 125 promotes types in powers of 2. The encoding of the three bits of the PROMOTE field 3003 is defined as shown in Table 11.

[0210]

[0211] Table 11

[0212] When PROMOTE is 000, it corresponds to a 1x promotion; each subelement is unchanged and occupies a vector lane of width equal to the size specified by ELTYPE. When PROMOTE is 001, it corresponds to a 2x promotion and zero extension; each subelement is treated as an unsigned integer and zero-extended to a vector lane of twice the width specified by ELTYPE. 2x promotion is invalid for an initial subelement size of 64 bits. When PROMOTE is 010, it corresponds to a 4x promotion and zero extension; each subelement is treated as an unsigned integer and zero-extended to a vector lane of four times the width specified by ELTYPE. 4x promotion is invalid for an initial subelement size of 32 bits or 64 bits. When PROMOTE is 011, it corresponds to an 8x promotion and zero extension; each subelement is treated as an unsigned integer and zero-extended to a vector lane of eight times the width specified by ELTYPE. 8x promotion is invalid for an initial subelement size of 16 bits, 32 bits, or 64 bits. When PROMOTE is 101, corresponding to 2x promotion and sign extension, each subelement is treated as a signed integer and sign-extended to a vector lane width twice the width specified by ELTYPE. 2x promotion is invalid for an initial subelement size of 64 bits. When PROMOTE is 110, corresponding to 4x promotion and sign extension, each subelement is treated as a signed integer and sign-extended to a vector lane width four times the width specified by ELTYPE. 4x promotion is invalid for an initial subelement size of 32 bits or 64 bits. When PROMOTE is 111, corresponding to 8x promotion and zero extension, each subelement is treated as a signed integer and sign-extended to a vector lane width eight times the width specified by ELTYPE. 8x promotion is invalid for an initial subelement size of 16 bits, 32 bits, or 64 bits.

[0213] The VECLEN field 3004 defines the length of the stream vector in bytes. The stream engine 125 decomposes the stream into groups of VECLEN bytes long. The encoding of the three bits of the VECLEN field 3004 is defined as shown in Table 12.

[0214] VECLEN Flow vector length 000 1 byte 001 2 bytes 010 4 bytes 011 8 bytes 100 16 bytes 101 32 bytes 110 64 bytes 111 reserve

[0215] Table 12

[0216] VECLEN cannot be smaller than the product of the element size in bytes and the repetition factor. As shown in Table 11, the maximum VECLEN of 64 bits is equal to the preferred vector size of the vector datapath side B116. When VECLEN is shorter than the native vector width of the processing unit core 110, the stream engine 125 pads the extra lanes in the vector provided to the processing unit core 110. The GRDUP field 3006 determines the type of padding. The VECLEN field 3004 interacts with the ELDUP field 3005 and the GRDUP field 3006 in the manner described below.

[0217] The ELDUP field 3005 specifies the number of times each element is repeated. The element size multiplied by the element repetition amount cannot exceed 64 bytes. The encoding of the three bits of the ELDUP field 3005 is defined as shown in Table 13.

[0218] ELDUP Repetition factor 000 No repetition 001 2 times 010 4 times 011 8 times 100 16 times 101 32 times 110 64 times 111 reserve

[0219] Table 13

[0220] The ELDUP field 3005 interacts with the VECLEN field 3004 and the GRDUP field 3006 in the manner described below. The nature of the relationship between the allowed element size, the element repetition factor, and the destination vector length requires that repeated elements that overflow the first destination register fill an integer number of destination registers after repetition is complete. The data from the additional destination registers ultimately supplies the corresponding stream head register 2818 / 2828. After the repetition of the first data element is complete, the next data element is rotated down to the least significant bit of the source register 3100, and the first data element is discarded. The process is then repeated for the new data element.

[0221] The GRDUP bit 3006 determines whether group repetition is enabled. If the GRDUP bit 3006 is 0, group repetition is disabled. If the GRDUP bit 3006 is 1, group repetition is enabled. When enabled by the GRDUP bit 3006, the stream engine 125 repeats a group of elements to fill the vector width. The VECLEN field 3004 defines the length of the group to be copied. When the VECLEN field 3004 is less than the vector length of the processing unit core 110 and the GRDUP bit 3006 enables group repetition, the stream engine 125 fills the additional lanes with additional copies of the stream vector (see Figure 21 and Figure 22 ). Because the stream vector length and the vector length of the processing unit core 110 are integer powers of 2, group repetition produces an integer number of repeated copies. Note that GRDUP and VECLEN do not specify the number of repetitions. The number of repetitions performed is preferably based on the ratio of VECLEN to the native vector length, which in this example is 64 bytes / 512 bits.

[0222] The GRDUP field 3006 specifies how the stream engine 125 pads the stream vectors after the VECLEN length to the vector length of the processing unit core 110. When the GRDUP bit 3006 is 0, the stream engine 125 fills the extra lanes with zeros and marks the extra vectors as invalid. When the GRDUP bit 3006 is 1, the stream engine 125 fills the extra lanes with copies of the element groups for each stream vector. When VECLEN is set to the native vector width of the processing unit core 110, setting the GRDUP bit 3006 to 1 has no effect. VECLEN must be at least as large as the product of ELEM_BYTES and the element repetition factor ELDUP. In other words, elements or repetition factors of elements cannot be separated using VECLEN.

[0223] Group repetition operates on the destination vector size. When the element size ELEM_BYTES multiplied by the element repetition factor ELDUP equals or exceeds the destination vector width, group repetition does not change the supplied data. Under such conditions, the state of the GRDUP bit 3006 and the VECLEN field 3004 does not affect the supplied data.

[0224] The following example setup illustrates the interaction between VECLEN and GRDUP. Each of the following examples shows how the stream engine maps a stream onto a vector spanning different stream vector lengths and vector sizes on the vector datapath side B116. The stream for this example includes twenty-nine elements (E0 to E28) of 64 bits / 8 bytes. The stream can be a linear stream of twenty-nine elements or an inner loop of 29 elements. The table illustrates ... Figure 21 Each illustrated vector is then stored in a corresponding stream head register 2818 / 2828.

[0225] Table 14 illustrates how an example stream is mapped onto bits within a 64-byte processor vector when VECLEN is 64 bytes.

[0226]

[0227] Table 14

[0228] The stream is extended over four vectors as shown in Table 14. As previously mentioned, the channels within the vector 4 that extend beyond the stream are filled with zeros. When VECLEN has a size equal to the native vector length, the value of GRDUP does not matter, because in the case of such VECLEN, no duplication can occur.

[0229] Table 15 shows the same parameters as shown in Table 14, except for the 32-byte VECLEN. Group repetition is disabled (GRDUP=0).

[0230]

[0231] Table 15

[0232] The twenty-nine elements of the stream are distributed across eight vectors, channels 0 through 3. The extra channels 4 through 7 in vectors 1 through 7 are filled with zeros. In vector 8, channel 1 has a stream element (E28), and the other channels are filled with zeros.

[0233] Except for the sixteen-byte VECLEN, Table 16 shows the same parameters as those shown in Table 14. Group repetition is disabled (GRDUP=0).

[0234]

[0235] Table 16

[0236] The twenty-nine elements of the stream are distributed across channels 0 to 1 in fifteen vectors. The extra channels 2 to 7 in vectors 1 to 14 are filled with zeros. In vector 15, channel 1 has a stream element (E28), and the other channels are filled with zeros.

[0237] Except for the eight-byte VECLEN, Table 17 shows the same parameters as those shown in Table 14. Group repetition is disabled (GRDUP=0).

[0238]

[0239]

[0240] Table 17

[0241] The twenty-nine elements of the stream appear in channel 0 of the twenty-nine vectors. The extra channels 1 through 7 in vectors 1 through 29 are filled with zeros.

[0242] Table 18 shows the same parameters as those shown in Table 15, except for the thirty-two-bit VECLEN. Group repetition is enabled (GRDUP=1).

[0243]

[0244] Table 18

[0245] The twenty-nine elements of the stream are distributed across channels 0 through 7 in eight vectors. Each of vectors 1 through 7 includes four repeated elements. The repetition factor (2) is due to the fact that VECLEN (32 bytes) is half the native vector length of 64 bytes. In vector 8, channel 0 has a stream element (E28) and channels 1 through 3 are zero-filled. This pattern is repeated for channels 4 through 7 of vector 9.

[0246] Except for the sixteen-byte VECLEN, Table 19 shows the same parameters as those shown in Table 16. Group repetition is enabled (GRDUP=1).

[0247]

[0248] Table 19

[0249] The twenty-nine elements of the stream are distributed across channels 0 through 7 in fifteen vectors. Each of vectors 1 through 7 consists of two elements repeated four times. The repetition factor (4) is a result of the fact that VECLEN (16 bytes) is one-quarter the native vector length of 64 bytes. In vector 15, channel 0 has a stream element (E28) and channel 1 is zero-filled. This pattern is repeated in channels 2 and 3, channels 4 and 5, and channels 6 and 7 of vector 15.

[0250] Except for the eight-byte VECLEN, Table 20 shows the same parameters as those shown in Table 17. Group repetition is enabled (GRDUP=1).

[0251]

[0252]

[0253] Table 20

[0254] All twenty-nine elements of the stream appear on channels 0 through 7 in the twenty-nine vectors. Each vector consists of one element repeated eight times. The repetition factor (8) is a result of the fact that the VECLEN (8 bytes) is one-eighth the native vector length of 64 bytes. Therefore, each channel is identical in vectors 1 through 29.

[0255] Figure 31 Instructions are included Figure 19 Example of a vector length mask / group repeat block 2025 within the formatter block 1903 of FIG. Input register 3100 receives data from Figure 202024 . The input register 3100 includes 64 bytes arranged into 64 1-byte blocks (byte 0 to byte 63). Note that the length of each byte 0 to byte 63 is equal to the minimum value of ELEM_BYTES. A set of multiplexers 3101 to 3163 couples the input bytes from the source register 3100 to the output register 3170. Each corresponding multiplexer 3101 to 3163 supplies the input to the corresponding byte 1 to byte 63 of the output register 3170. Not all bytes (byte 0 to byte 63) of the input register 3100 are coupled to each multiplexer 3101 to 3163. It should be noted that no multiplexer supplies byte 0 of the output register 3170. In this example, byte 0 of the output register 3170 is supplied by byte 0 of the input register 3100.

[0256] Multiplexers 3101 through 3163 are controlled by multiplexer control encoder 3180. Multiplexer control encoder 3180 receives the ELEM_BYTES, VECLEN, and GRDUP input signals and generates corresponding control signals for multiplexers 3101 through 3163. ELEM_BYTES and ELDUP are supplied to multiplexer control encoder 3180 to check that VECLEN is at least as large as the product of ELEM_BYTES and ELDUP. In operation, multiplexer control encoder 3180 controls multiplexers 3101 through 3163 to transfer the least significant bit (LSB) equal to VECLEN from input register 3100 to output register 3170. If GRDUP = 0, indicating that group repetition is disabled, multiplexer control encoder 3180 controls the remaining multiplexers 3101 through 3163 to transfer zeros to all bits in the remaining most significant channel of output register 3170. If GRDUP=1, indicating that group repeat is enabled, the multiplexer control encoder 3180 controls the remaining multiplexers 3101 to 3163 to repeat the VECLEN number of least significant bits of the input register 3100 into the most significant channel of the output register 3170. This control is similar to the element repeat control described above, and fills the output register 3170 with the first vector. For the next vector, the data in the input register 3100 is rotated down by VECLEN, discarding the previous VECLEN least significant bits. By the processing unit core 110 ( Figure 1 ) sets the formatter 1903 at the rate at which data is consumed via stream read advance instructions as described below ( Figure 19 ) The set of repeated formatting is repeated as long as the stream includes additional data elements.

[0257] Element repetition (ELDUP) and group repetition (GRUDP) are independent. Note that these features have independent specifications and parameter settings. Therefore, element repetition and group repetition can be used together or separately. Because they are specified, element repetition allows overflow to the next vector, while group repetition does not.

[0258] Reference again Figure 30 The DECIM field 3007 controls the extraction of data elements from the corresponding stream. The stream engine 125 deletes data elements from the stream on the storage device in the corresponding stream head register 2818 / 2828 for presentation to the requesting functional unit. Extraction removes entire data elements, not sub-elements. The DECIM field 3007 is defined as listed in Table 21.

[0259] DECIM Decimation Factor 00 No extraction 01 2 times 10 4 times 11 reserve

[0260] Table 21

[0261] If the DECIM field 3007 is equal to 00, no extraction occurs. The data elements are passed to the corresponding stream header registers 2818 / 2828 unchanged. If the DECIM field 3007 is equal to 01, a 2:1 extraction occurs. After being stored in the stream header registers 2818 / 2828, the stream engine 125 removes the odd elements from the data stream. The limitations of the formatting network require that the 2:1 extraction used has at least 2 times the data promotion (PROMOTE cannot be 000), ICNT0 must be a multiple of 2, and the total vector length (VECLEN) must be large enough to hold a single promoted repeated element. For transposed streams (TRANSPOSE≠0), the transposition granule must be at least twice the element size in bytes before promotion. If the DECIM field 3007 is equal to 10, a 4:1 extraction occurs. After the data stream is stored in the stream head register 2818 / 2828, the stream engine 125 retains every fourth data element, i.e., removes three elements from every four data elements in the data stream. Constraints of the formatting network require that the 4:1 extraction used has at least 4 times the data promotion (PROMOTE cannot be 000, 001, or 101), ICNT0 must be a multiple of 4, and the total vector length (VECLEN) must be large enough to hold a single promoted repeated element. For a transposed stream (TRANSPOSE≠0), in one example, the extraction removes columns and does not remove rows. Therefore, in this case, for a 2:1 extraction, the transposition granularity must be at least twice the element size in bytes before promotion (GRANULE ≥ 2×ELEM_BYTES), and for a 4:1 extraction, the transposition granularity must be at least four times the element size in bytes before promotion (GRANULE ≥ 4×ELEM_BYTES).

[0262] The THROTTLE field 3008 controls how aggressively the stream engine fetches ahead of the processing unit core 110. The encoding of the two bits of this field is defined as shown in Table 22.

[0263] THROTTLE describe 00 Minimum throttling, maximum early withdrawal 01 Less throttling, more early withdrawals 10 More throttling, less early withdrawals 11 Maximum throttling, minimum early withdrawal

[0264] Table 22

[0265] THROTTLE does not change the meaning of the stream and serves only as a hint. The stream engine can ignore this field. Programs should not rely on specific throttling behavior to judge program correctness, because the architecture does not specify precise throttling behavior. THROTTLE allows programmers to provide hints to the hardware about program behavior. By default, the stream engine tries to be as far ahead of the processing unit core 110 as possible to hide as much latency as possible (equivalent to THROTTLE=11), while providing sufficient stream throughput to the processing unit core 110. Although some applications require this level of throughput, this throughput may lead to poor system-level behavior for other applications. For example, the stream engine discards all extracted data that passes through context switches. Therefore, aggressive advance extraction may lead to bandwidth waste in systems with a large number of context switches.

[0266] The DIMFMT field 3009 defines which of the loop count fields ICNT0 2901, ICNT1 2902, ICNT2 2903, ICNT3 2804, ICNT4 2905, and ICNT5 2906 of the stream template register 2900, which of the loop dimension fields DIM1 2911, DIM2 2912, DIM3 2913, DIM4 2914, and DIM5 2915, and which of the addressing mode fields AM0 3013, AM1 3014, AM2 3015, AM3 3016, AM4 3017, and AM5 3018 (part of the FLAGS field 2921) are valid for this particular stream. Table 23 lists the valid loops for various values ​​of the DIMFMT field 3009. Each valid loop count must be at least 1, and the outer valid loop count must be greater than 1.

[0267]

[0268] Table 23

[0269] The DIR bit 3010 determines the fetch direction for the inner loop (loop 0). If the DIR bit 3010 is 0, loop 0 is fetched in the forward direction toward increasing addresses. If the DIR bit 3010 is 1, loop 0 is fetched in the reverse direction toward decreasing addresses. The fetch direction for the other loops is determined by the signs of the corresponding loop dimensions DIM1, DIM2, DIM3, DIM4, and DIM5.

[0270] The CBK0 field 3011 and the CBK1 field 3012 control the loop block size based on the selection of loop addressing.The manner in which the loop block size is determined is described herein.

[0271] The AM0 field 3013, the AM1 field 3014, the AM2 field 3015, the AM3 field 3016, the AM4 field 3017, and the AM5 field 3018 control the addressing mode of the corresponding loop, thereby allowing the addressing mode to be specified independently for each loop. Each of the AM0 field 3013, the AM1 field 3014, the AM2 field 3015, the AM3 field 3016, the AM4 field 3017, and the AM5 field 3018 is three bits and is decoded as listed in Table 24.

[0272] AMx field meaning 00 Linear addressing 01 The circular addressing block size is set by CBK0 10 The circular addressing block size is set by CBK0+CBK1+1 11 reserve

[0273] Table 24

[0274] In linear addressing, the address advances depending on whether the address algorithm is forward or reverse. In circular addressing, the address remains within a defined address block. After reaching the end of the circular address block, the address wraps around to the beginning of the block. Circular addressing blocks are limited to 2 N addresses, where N is an integer. The circular address algorithm can operate by cutting off carry chains between bits and not allowing a selected number of most significant bits to change. Thus, the algorithm that goes beyond the end of the circular block changes only the least significant bits. The block size is set as listed in Table 25.

[0275]

[0276] Table 25

[0277] In this example, the cyclic block size is set by the value encoded by CBK0 (first cyclic address mode 01) or by the value encoded by CBK0+CBK1+1 (second cyclic address mode 10). For example, in the first cyclic address mode, the cyclic address block size can range from 512 bytes to 16M bytes. For the second cyclic address mode, the cyclic address block size can range from 1K bytes to 64G bytes. Therefore, the encoded block size is 2 (B+9) Bytes, where B is the number of coded blocks, which is CBK0 for the first block size (AMx is 01) and CBK0+CBK1+1 for the second block size (AMx is 10).

[0278] Processing unit 110 ( Figure 1 ) enables the stream engine 125 ( Figure 28) is programmed. The program uses SEOPEN and SECLOSE to start and end streams. SEOPEN starts a new stream, and the stream remains open until it is explicitly terminated by SECLOSE or replaced by a new stream by SEOPEN. The SEOPEN instruction specifies the stream number indicating the start of stream 0 or stream 1. The SEOPEN instruction specifies the data register that stores the starting address of the stream. The SEOPEN instruction also specifies the stream template register that stores the stream template described above. The arguments of the SEOPEN instruction are listed in Table 26.

[0279] variables describe Stream start address register Scalar register storing the stream start address Stream Number Stream 0 or Stream 1 Stream Template Register Vector registers storing stream template data

[0280] Table 26

[0281] In this example, the stream start address register is the general scalar register file 211 ( Figure 2 ) in the register. The SEOPEN instruction can be encoded via the example instruction 1300 ( Figure 13 )'s src1 field 1303( Figure 13 ) specifies the stream start address. The SEOPEN instruction specifies stream 0 or stream 1 in the opcode. In this example, the stream template register is a vector register in the general vector register file 221. The SEOPEN instruction can be used to open the stream template register 1302 via the src2 / cst field 1302 ( Figure 13 ) specifies the stream template register. If the specified stream is active, the SEOPEN instruction closes the previous stream and replaces it with the specified stream.

[0282] SECLOSE explicitly marks the stream as inactive and flushes any outstanding activity. Any other reference to the stream will trigger an exception. SECLOSE also allows the program to terminate one or both streams prematurely.

[0283] The SESAVE instruction saves the state of a stream by capturing sufficient state information for the specified stream to restart the stream in the future. The SERSTR instruction resumes a previously saved stream. The SESAVE instruction saves stream metadata and does not save any stream data. The stream is retrieved in response to the SERSTR instruction.

[0284] Each flow can be in one of three states: inactive, active, or frozen after a reset. Both flows start in the inactive state. Opening a flow moves it to the active state. Closing a flow returns it to the inactive state. In the absence of interruptions and exceptions, a flow typically does not transition to other states. To address interruptions, the flow engine adds a third state: frozen. The frozen state represents an active flow that has been interrupted.

[0285] In this example, four bits (two bits per stream) define the state of the two streams. One bit per stream resides within the stream engine, and the other bit resides within the processor core 110. The stream engine internally tracks whether each stream maintains the parameter set associated with the active stream. This bit distinguishes inactive streams from non-inactive streams. The processor core 110 uses dedicated bits for each stream in the task status register (TSR) to track the state of each stream separately: TSR.SE0 for stream 0 and TSR.SE1 for stream 1. These bits distinguish between active and inactive streams.

[0286] Opening a stream moves the stream to the active state. Closing a stream moves the stream to the inactive state. If a program opens a new stream on a frozen stream, the new stream replaces the old one, and the stream engine discards the contents of the previous stream. The stream engine supports opening a new stream on a currently active stream. The stream engine discards the contents of the previous stream, flushes the pipeline, and begins extracting data from the newly opened stream. Once the data is returned, the data becomes available to the processor. If a program closes a stream that has already been closed, nothing happens. If a program closes an open or frozen stream, the stream engine discards all state associated with the stream, clears the internal stream active bit, and clears the counter, tag, and address registers. Closing a stream serves two purposes. Closing an active stream allows a program to specifically declare that the stream and its associated resources are no longer needed. Closing a frozen stream also allows context switch code to clean up the frozen stream's state so that other tasks do not see it.

[0287] As described above, there are situations where some data within stream holding register 2818 or 2828 is invalid. As described above, this situation can occur at the end of an inner loop when the number of stream elements is less than the size of the corresponding stream holding register 2818 / 2828, or when the number of remaining stream elements is less than the number of lanes defined by VECLEN. For times not at the end of an inner loop, if VECLEN is less than the width of stream holding register 2818 / 2828 and GRDUP is disabled, the lanes in stream holding register 2818 / 2828 beyond VECLEN are invalid.

[0288] Reference again Figure 28In this example, the stream engine 125 further includes valid registers 2819 and 2829. Valid register 2819 indicates the valid channels in stream head register 2818. Valid register 2829 indicates the valid channels in stream head register 2828. The corresponding valid registers 2819 / 2829 include one bit for each minimum ELEM_BYTES channel in the corresponding stream head register 2818 / 2828. In this example, the minimum ELEM_BYTES is 1 byte. The preferred data path width of the processor 100 and the data length of the stream head register 2818 / 2828 are 64 bytes (512 bits). Therefore, the valid registers 2819 / 2829 have a data width of 64 bits. Each bit in the valid registers 2819 / 2829 indicates whether the corresponding byte in the stream head register 2818 / 2828 is valid. In this example, 0 indicates that the corresponding byte in the stream head register is invalid, and 1 indicates that the corresponding bit is valid.

[0289] In this example, upon reading a corresponding one of the stream head registers 2818 / 2828 and transferring the data to the requesting functional unit, the invalid / valid data in the corresponding valid register 2819 / 2829 is automatically transferred to the predicate register file 243 ( Figure 2 ) In this example, valid data for stream 0 is stored in predicate register P0, and valid data for stream 1 is stored in predicate register P1.

[0290] This valid data stored in the predicate register file 234 can be used in various ways. A functional unit can use the valid data indication as a mask to combine vector stream data with another set of vectors and then store the combined data to memory, thereby allowing the same process to be used at the end of the loop data as for the case where all lanes are valid, which avoids storing invalid data. The valid indication stored in the predicate register file 234 can be used as a mask or operand in other processes. P unit 246 ( Figure 2 ) may have an instruction (BITCNT) for counting the number of 1s in a predicate register, which may be used to determine a count of valid data elements from a predicate register.

[0291] Figure 32 Description is used to generate the data stored in valid register 2819 ( Figure 28 ) in example hardware 3200 for valid / invalid indication. Figure 32 The hardware for stream 0 is described; stream 1 includes corresponding hardware. The hardware 3200 operates to register the stream head register 2818 ( Figure 28) is updated in the decoder 3201. The first input ELTYPE is supplied to the decoder 3201. The decoder 3201 generates an output "TOTAL ELEMENT SIZE" corresponding to the minimum data size based on the element size ELEM_BYTES and whether the element is a real number or a complex number. The meaning of each encoding of ELTYPE is shown in Table 9. Table 27 shows an example output of the decoder 3201 in bytes for each ELTYPE encoding. It should be noted that Table 9 lists bits and Table 27 lists bytes. As shown in Table 27, if the element is a real number, TOTAL ELEMENT SIZE is 1, 2, 4 or 8 bytes, and if the element is a complex number, TOTAL ELEMENT SIZE is 2, 4, 8 or 16 bytes.

[0292]

[0293] Table 27

[0294] The second input, PROMOTE, is supplied to decoder 3202. Decoder 3202 generates an output boost factor corresponding to the PROMOTE input. The meaning of each PROMOTE encoding is shown in Table 28, which shows an example output of decoder 3202 in bytes for each PROMOTE encoding. The difference in extension type (zero extension or sign extension) is irrelevant to decoder 3202.

[0295]

[0296] Table 28

[0297] The outputs of decoders 3201 and 3202 are supplied to multiplier 3203. The product produced by multiplier 3202 is the channel size corresponding to TOTAL ELEMENT SIZE and the lifting factor. Since the lifting factor is an integer power of 2 (2 N ), so the multiplication can be implemented by a corresponding shift of TOTAL ELEMENT SIZE. For example, there is no shift when the lifting factor is 1, a shift of 1 when the lifting factor is 2, a shift of 2 when the lifting factor is 4, and a shift of 3 when the lifting factor is 8.

[0298] The "NUMBER OF LANES" unit 3204 receives the vector length VECLEN and the lane size (LANESIZE) and generates NUMBER OF LANES. Table 29 shows an example decoding of multiple lanes for the lane size in bytes and the vector length VECLEN.

[0299]

[0300] Table 29

[0301] As mentioned above, VECLEN must be greater than or equal to the product of the element size and the repetition factor. As shown in Table 29, VECLEN must also be greater than or equal to the product of the element size and the promotion factor. This means that VECLEN must be large enough to ensure that the element cannot be separated from it by the type promotion block 2022 ( Figure 20 ) The cells marked with "-" below the diagonal in Table 29 indicate parameter combinations that are not allowed.

[0302] The output of unit 3204, "NUMBER OF LANES," serves as one input to "LANE / REMAINING ELEMENTS CONTROL WORD" unit 3211. The second input comes from multiplexer 3212. Multiplexer 3212 receives the Loop0 input and the Loop1 input. The Loop0 input and the Loop1 input represent the number of remaining elements in the current iteration of the corresponding loop.

[0303] Figure 33 illustrate Figure 28 , a partial schematic diagram of the address generator 2811 is shown in FIG. Address generator 2811 forms an address for extracting the next element in the defined stream of the corresponding stream engine. Start address register 3301 stores the starting address of the data stream. As previously described, in this example, start address register 3301 is a scalar register in the global scalar register file 211 that is identified by the SEOPEN instruction that starts the corresponding stream. This starting address can be copied from a designated scalar register by control logic included in address generator 2811 and stored locally at the corresponding address generator 2811 / 2821. The first loop of the stream utilizes Loop0 count register 3311, adder 3312, multiplier 3313, and comparator 3314. Loop0 count register 3311 stores a working copy of the iteration count for the first loop (Loop0). For each iteration of Loop0 adder 3312, when triggered by the next address signal, the loop count is incremented by 1 and stored back in Loop0 count register 3311. Multiplier 3313 multiplies the current loop count by the value ELEM_BYTES. ELEM_BYTES is the size in bytes of each data element in Loop 0. Loop 0 traverses physically consecutive data elements in memory with an iteration step size of ELEM_BYTES.

[0304] Comparator 3314 compares the count stored in Loop0 count register 3311 (after being incremented by adder 3313) with the count from the corresponding flow template register 2900 ( Figure 29 ICNT0 2901( Figure 29 ) is compared with the value of . When the output of adder 3312 is equal to the value of ICNT0 2901 in stream template register 2900, the iteration of Loop0 is completed. Comparator 3314 generates a valid Loop0 end signal. Loop0 count register 3311 is reset to 0 and the iteration of the next higher loop (in this case, Loop1) is triggered.

[0305] The circuit for higher loops (Loop1, Loop2, Loop3, Loop4 and Loop5) is similar to Figure 33 . Each loop includes a corresponding working cycle count register, an adder, a multiplier, and a comparator. The adder of each loop is triggered by the loop end signal of the previous loop. The second input of each multiplier is the corresponding dimension DIM1, DIM2, DIM3, DIM4, and DIM5 from the corresponding flow template. The comparator of each loop compares the working cycle register count with the corresponding iteration value ICNT1, ICNT2, ICNT3, ICNT4, and ICNT5 of the corresponding flow template register 2900. The loop end signal generates the iteration of the next higher loop. The loop end signal from Loop5 ends the flow.

[0306] Figure 33 The generation of the Loop0 count is also described. The Loop0 count is equal to the update data stored in the corresponding working count register 3311. The Loop0 count is updated every time the working Loop0 count register 3311 changes. The loop counts for higher loops (Loop1, Loop2, Loop3, Loop4, and Loop5) are generated similarly.

[0307] Figure 33 The generation of the Loop0 address is also described. The Loop0 address is equal to the data output from multiplier 3313. The Loop0 address is updated with each change in the working Loop0 counter register 3311. Similar circuits for Loop1, Loop2, Loop3, Loop4, and Loop5 generate the corresponding loop addresses. In this example, Loop0 counter register 3311 and the other loop counter registers are implemented as up-counting registers. In another example, the initialization and comparison operations are implemented as down-counting circuits.

[0308] Reference again Figure 32 The value of the loop down count (such as Loop0 / ) can be given by Loopx / =ICNTx-Loopx, that is, the loop down count is the initial iteration count specified in the flow template register and the value of the loop down count (such as Loop0 / ) can be given by Loopx / =ICNTx-Loopx. Figure 33 The difference between the resulting cycle up counts is shown.

[0309] LANE / REMAINING ELEMENTS CONTROL WORD unit 3211( Figure 32 ) generates a control word 3213 based on the number of channels from the NUMBER OFLANES unit 3204 and the cyclic down count selected by the multiplexer 3212. The control input to the multiplexer 3212 is from Figure 30 TRANSPOSE signal of field 3002 of . If TRANSPOSE is disabled ("000"), multiplexer 3212 selects Loop 0 (counted down, Loop 0 / ). For all other legal values ​​of TRANSPOSE ("001," "010," "011," "100," "101," and "110"), multiplexer 3212 selects Loop 1 (counted down, Loop 1 / ). The stream engine maps the innermost dimension to consecutive lanes in the vector. For normal streams, this is Loop 0. For transposed streams, this is Loop 1, because the transposition swaps the two dimensions.

[0310] LANE / REMAINING ELEMENTS CONTROL WORD unit 3211 generates a control word 3213 as shown below. Control word 3213 has a number of bits equal to the number of lanes from unit 3204. If the remaining count of the elements of the selected loop is greater than or equal to the number of lanes, then all lanes are valid. For this case, control word 3213 is all ones, which indicates that all lanes within the vector length VECLEN are valid. If the remaining count of the elements of the selected loop is non-zero and less than the number of lanes, then some lanes are valid and some lanes are invalid. Based on the above combined Figure 21 and Figure 22 The lane assignments described above assign lanes to stream elements starting with the least significant lane. In these cases, the control word 3213 includes a number of least significant bits set to one equal to the number of selected loop down counts. All other bits of the control word 3213 are set to zero. Figure 32 In the example illustrated in , the number of lanes is equal to eight and there are five valid (1) least significant bits followed by three invalid (0) most significant bits, which corresponds to a loop with five elements remaining in the final iteration.

[0311] The control word expansion unit 3214 expands the control word 3213 based on the value of the LANE SIZE. The expanded control word includes one bit for each minimum size lane. In this example, the minimum stream element size is 1 byte (8 bits), and therefore the minimum lane size is one byte (8 bits). In this example, the size of the holding registers 2818 / 2828 is equal to the vector size of 64 bytes (512 bits). Therefore, the expanded control word has 64 bits, one bit for each byte of the stream holding registers 2818 / 2828. This expanded control word fills the corresponding valid registers 2819 and 2829 ( Figure 28 )'s least significant bit.

[0312] For the case where VECLEN is equal to the vector length, this description is complete. The extended control word includes bits for all positions within the corresponding valid register 2819 / 2829. There are some additional considerations when VECLEN is not equal to the vector length. When VECLEN is not equal to the vector length, the extended control word does not have enough bits to fill the corresponding valid register 2819 / 2829. Figure 32 As illustrated, the extended control word fills the least significant bits of the corresponding valid registers 2819 / 2829, thus providing valid / invalid bits for lanes within the VECLEN width.Another mechanism is provided for lanes exceeding the VECLEN width up to the data width of the stream head register 2818.

[0313] Still refer to Figure 32 , illustrating the multiplexer 3215 and group repeat unit 3216 to provide the required additional valid / invalid bits. Referring to the description of VECLEN, if group repeat is not enabled (GRDUP=0), the excess lanes are invalid. The first input to the multiplexer 3215 is the INVALID 0 signal, which includes a number of bits equal to VECLEN. When GRDUP=0, the multiplexer 3215 selects this input. The group repeat unit 3216 repeats this input to all excess lanes of the stream head register 2818. Therefore, the most significant bit of the valid register 2819 is set to zero, indicating that the corresponding byte of the stream head register 2818 is invalid. This occurs for vectors 1 to 8 of the example shown in Table 15, vectors 1 to 15 of the example shown in Table 16, and vectors 1 to 29 of the example shown in Table 17.

[0314] In another example, the multiplexer 3215 and the group repeat block 3216 are replaced with Figure 31 The group repetition logic 2025 described above is similar to the group repetition logic.

[0315] As previously described, if group duplication is enabled (GRDUP=1), the stream head register 2818 ( Figure 28 ) are filled with copies of the least significant bits. The second input to the multiplexer 3215 is the extended control word from the control word extension unit 3214. When GRDUP=1, the multiplexer 3215 selects this input. The group repeat unit 3216 repeats this input to all excess lanes of the stream head register 2818.

[0316] There are two possible outcomes. In one outcome, in most cases, all lanes within the VECLEN are valid and the bits from the control word extension unit 3214 are all ones. This occurs in vectors 1 through 7 of the group repetition example shown in Table 18 and vectors 1 through 14 of the group repetition example shown in Table 19. In these cases, all bits of the extended control word from the control word extension unit 3214 are ones, and all lanes of the stream head register 2818 are valid. Therefore, the group repetition unit 3216 fills all excess lanes with ones. In the other outcome, the number of remaining stream data elements is less than the number of lanes within the VECLEN. This occurs in vector 8 of the group repetition example shown in Table 18 and vector 15 of the group repetition example shown in Table 19. In these cases, some lanes within the VECLEN are valid and some are invalid. The group repetition unit 3216 fills the excess lanes with bits having the same pattern as the extended control word bits. In either case, the excess lanes corresponding to the extended control bits are filled.

[0317] Still refer to Figure 32 , illustrating the boundary between the least significant bit and the most significant bit 3217. The location of this boundary is set by the size of the VECLEN relative to the size of the stream head register 2818.

[0318] Figure 34 is a partial diagram 3400 illustrating the encoding of the stream input operands described above. Figure 34 The instruction decoder 113 (see FIG. 13 ) illustrates decoding the src1 field 1303 of an instruction to control the corresponding src1 input of the functional unit 3420. Figure 1 ) is part of the instruction control functional unit 3420. These same or similar circuits are repeated for the src2 / cst field 1302 of the instruction control functional unit 3420. Furthermore, these circuits are repeated for each instruction within the execution packet that is capable of taking streaming data as operands that are dispatched simultaneously.

[0319] The instruction decoder 113 receives the src1 field 1303 containing the instruction. The opcode field 1304 and the unit field 1305 specify the corresponding functional unit 3420 and the function to be performed. In this example, the functional unit 3420 can be the L2 unit 241, the S2 unit 242, the M2 unit 243, the N2 unit 244, or the C unit 245. Figure 34 The relevant portion of the instruction decoder 113 illustrated in FIG. 1 decodes the src1 field 1303. The sub-decoder 3411 determines whether the src1 field 1303 is within the range of 00000 to 01111. If so, the sub-decoder 3411 supplies the corresponding register number to the global vector register file 231. In this example, the register number is the four least significant bits of the src1 field 1303. The global vector register file 231 calls the data stored in the register corresponding to the register number and supplies the data to the src1 input of the functional unit 3420.

[0320] Subdecoder 3412 determines whether src1 field 1303 is within the range of 10000 to 10111. If so, subdecoder 3412 supplies the corresponding register number to the corresponding local vector register file. If the instruction is directed to L2 unit 241 or S2 unit 242, the corresponding local vector register file is local vector register file 232. If the instruction is directed to M2 unit 243, N2 unit 244, or C unit 245, the corresponding local vector register file is local vector register file 233. In this example, the register number is the three least significant bits of src1 field 1303. The corresponding local vector register file 232 / 233 calls the data stored in the register corresponding to the register number and supplies the data to the src1 input of functional unit 3420.

[0321] The subdecoder 3413 determines whether the src1 field 1303 is 11100. If so, the subdecoder 3413 supplies a stream 0 read signal to the stream engine 125. The stream engine 125 then supplies the stream 0 data stored in the holding register 2818 to the src1 input of the functional unit 3420.

[0322] Subdecoder 3414 determines whether src1 field 1303 is 11101. If so, subdecoder 3414 supplies a stream0 read signal to stream engine 125. Stream engine 125 then supplies the stream0 data stored in holding register 2818 to the src1 input of functional unit 3420. Subdecoder 3414 also supplies an advance signal to stream0. As previously described, stream engine 125 advances the next consecutive vector of data elements for stream0 stored in holding register 2818.

[0323] Supplying a stream 0 read signal to the stream engine 125 via the subdecoder 3413 or the subdecoder 3414 triggers another data movement. Based on this stream 0 read signal, the stream engine 125 supplies the data stored in the valid register 2819 to the predicate register file 234 for storage. According to this example, this is a predetermined data register within the predicate register file 234. In this example, data register P0 corresponds to stream 0.

[0324] The subdecoder 3415 determines whether the src1 field 1303 is 11110. If so, the subdecoder 3415 supplies a stream 1 read signal to the stream engine 125. The stream engine 125 then supplies the stream 1 data stored in the holding register 2828 to the src1 input of the functional unit 3420.

[0325] Subdecoder 3416 determines whether src1 field 1303 is 11111. If so, subdecoder 3416 supplies a stream 1 read signal to stream engine 125. Stream engine 125 then supplies the stream 1 data stored in holding register 2828 to the src1 input of functional unit 3420. Subdecoder 3414 also supplies an advance signal to stream 1. As previously described, stream engine 125 advances the next consecutive vector of data elements for stream 1 in holding register 2828.

[0326] Supplying a stream 1 read signal to the stream engine 125 via the subdecoder 3415 or the subdecoder 3416 triggers another data movement. Based on this stream 1 read signal, the stream engine 125 supplies the data stored in the valid register 2829 to the predicate register file 234 for storage. According to this example, this is a predetermined data register within the predicate register file 234. In this example, the data register P1 corresponds to stream 1.

[0327] Similar circuitry is used to select data supplied to the src2 input of the functional unit 3402 in response to the bit encoding of the src2 / cst field 1302. A constant input may be supplied to the src2 input of the functional unit 3520 in the manner described above. If the instruction decoder 113 generates a read signal for stream 0 from the src1 field 1303 or the src2 / sct field 1302, the stream engine 125 supplies the data stored in the valid register 2819 to the predicate register P0 of the stored predicate register file 234. If the instruction decode 113 generates a read signal for stream 1 from the src1 field 1303 or the src2 / sct field 1302, the stream engine 125 supplies the data stored in the valid register 2829 to the predicate register P1 of the stored predicate register file 234.

[0328] The exact number of instruction bits dedicated to operand specification, as well as the number of data registers and streams, is a design choice. In particular, specification of a single global vector register file and omission of local vector register files is possible. This example uses a bit encoding of the input operand select field to indicate a stream read and another bit encoding to indicate a stream read and advance the stream.

[0329] Figure 34 The process described in

[15] automatically transfers valid data to predicate register file 234 each time streaming data is read. The transferred valid data is then used by P unit 246 for further computation of metadata. The transferred valid data can also be used as a mask or operand for other operations via one or more vector datapath-side B116 functional units, including L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, and C unit 245. A large number of complex logic operations are possible using this streaming valid data.

[0330] Figure 35 is a partial schematic diagram 3500 illustrating another example configuration for selecting operand sources. In this example, the corresponding stream valid registers 2819 / 2829 do not need to be automatically loaded into predetermined registers in the predicate register file 234. Instead, explicit instructions to the P unit 246 are used to move data. Figure 35 Description of the instruction decoder 113 (see Figure 1 ) that decodes the src1 field 1303 of an instruction to control the corresponding src1 input of the P unit 246. These same or similar circuits can be replicated for the src2 / cst field 1302 ( Figure 13 ).

[0331] The instruction decoder 113 receives the instruction's src1 field 1303. The opcode field 1304 and unit field 1305 specify the P unit 246 and the function to be performed. Figure 35 The relevant portion of the instruction decoder 113 illustrated in FIG. 1 decodes the src1 field 1303. The sub-decoder 3511 determines whether the src1 field 1303 is within the range of 00000 to 01111. If so, the sub-decoder 3511 supplies the corresponding register number to the global vector register file 231. In this example, the register number is the four least significant bits of the src1 field 1303. The global vector register file 231 calls the data stored in the register corresponding to the register number and supplies the data to the src1 input of the P unit 246.

[0332] Subdecoder 3512 determines whether src1 field 1303 is within the range of 10000 to 10111. If so, subdecoder 3512 supplies the decoded register number to predicate register file 234. In this example, the register number is the three least significant bits of src1 field 1303. Predicate register file 234 calls the data stored in the register corresponding to the register number and supplies the data to the src1 input of predicate unit 246.

[0333] The subdecoder 3513 determines whether the src1 field 1303 is 11100. If so, the subdecoder 3513 supplies a stream 0 valid read signal to the stream engine 125. The stream engine 125 then supplies the valid data stored in the valid register 2819 to the src1 input of the P unit 246.

[0334] The subdecoder 3514 determines whether the src1 field 1303 is 11101. If so, the subdecoder 3514 supplies a stream 1 valid read signal to the stream engine 125. The stream engine 125 then supplies the stream 1 valid data stored in the valid register 2829 to the src1 input of the P unit 246.

[0335] The P-unit 246 instructions that use the stream valid registers 2819 / 2829 as operands can be any of the P-unit instructions described above, such as: NEG, BITCNT, RMBD, DECIMATE, EXPAND, AND, NAND, OR, NOR, and XOR.

[0336] The above specific instructions may be restricted to P unit 242. Therefore Figure 34 and Figure 35 If the functional unit specified by the instruction is the L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244 or C unit 245, the src1 field 1303 is interpreted as Figure 34 If the functional unit specified by the instruction is a P-unit 246, then the src1 field 1303 is interpreted as for Figure 35 As outlined. Alternatively, Figure 34 The automatic saving of the stream valid register to the predetermined predicate register described in may be implemented in one example and not implemented in another example.

[0337] As previously referenced in this article Figure 28As described above, the stream engine 125 organizes the corresponding data storage 2816 / 2826 into an array of gaps tagged with metadata, which includes a 49-bit virtual address, a valid bit, a ready bit, an activation bit, and a last reference value associated with the gap. Storage dispatch and tracking 2814 / 2824 manages the contents of the corresponding data storage 2816 / 2826 and maintains metadata for each gap. Table 30 shows possible state combinations of the valid bit, the ready bit, and the activation bit. Metadata may be referred to as a tag in this article, and the valid bit, the ready bit, and the activation bit within the metadata may be collectively referred to as a tag bit in this article.

[0338]

[0339] Table 30

[0340] For each address in each outgoing command, the storage dispatch and tracking 2814 / 2824 performs the following tag lookup to determine whether the data at the requested address is already in the corresponding data storage 2816 / 2826. Initially, the storage dispatch and tracking 2814 / 2824 compares the address with the relevant tag in the corresponding tag array. If a tag match is found, i.e., a hit, the outgoing command is canceled and the gap number that matches the address is remembered. If no tag match is found, i.e., a miss, an idle gap is dispatched for the address, the valid bit is set to 1, and the ready bit is set to 0. In addition, the outgoing command is updated to direct the data to the dispatched gap, the reference is inserted into the reference queue, the active bit is set to 1 to indicate the active reference in the reference queue, and the last reference of the gap is updated to the value of the insertion pointer of the reference in the reference queue.

[0341] To maximize the reuse of gaps and minimize stalls, storage dispatch and tracking 2814 / 2824 typically dispatches gaps in the following manner: 1) If available, select the gap immediately following the most recently dispatched gap (FIFO order); 2) Otherwise, select the next available gap in FIFO order (if any); 3) If no gap is available, stall the address generator 2811 / 2821 and repeat the above two steps until the dispatch is successful. This method tends to dispatch gaps in FIFO order that matches the general memory access behavior of the stream engine 125, but avoids stalls in cases where the specific reuse pattern of gaps works against the FIFO order. In addition, older tags (memory locations that were dispatched earlier in the stream sequence) will be replaced before newer tags.

[0342] The address generator 2811 / 2821 cannot generate a new address until a previously generated address is dispatched to a slot, so when no slot is available for dispatch, the address generator 2811 / 2821 waits (stalls) until a slot becomes available. As long as the reference queue 2815 / 2825 has entries, the stall of the address generator 2811 / 2821 does not stop the CPU read path.

[0343] Using a conventional FIFO approach to select the next available slot if the slot immediately following the most recently dispatched slot is not available may result in scanning the entire set of tags, thirty-two tags in this example, starting with the last dispatched slot. Figure 36 The example of illustrates this conventional FIFO approach. In this example, the scan of the tag bits begins at the current pointer (CP) position (the position immediately after the last assigned slot). In this example, the scan to locate an available slot begins with the CP pointing to the tag of slot 3 and ends with slot 8, which is determined to be available. Slot 8 is assigned to the address that triggers the scan, and the CP is then directed to slot 9. The next time an available slot is needed, the scan to locate an available slot begins with the tag of slot 9 and ends with slot 17, which is determined to be available. Slot 17 is assigned to the address that triggers the scan, and the CP is then directed to slot 18.

[0344] In some examples, storage dispatch and tracking 2814 / 2824 uses a pseudo FIFO tag replacement strategy to find available slots. Rather than scanning all tags of all slots in FIFO order until an available slot is located or all tags have been scanned, the tags are grouped into non-overlapping groups of consecutive tags, e.g., Figure 37 As shown, there are four groups of eight tags for eight consecutive gaps, and a single group is searched in a clock cycle. More specifically, when an available gap is needed, the search starts from the current group (CG) of tags (i.e., the group where the gap was last dispatched) at the location of the CP. If an available gap is found in the current group, the gap is dispatched, the CP moves to the tag of the next gap after the dispatched gap, and the current group remains the current group. For example, in Figure 37 In , the current group is group 0, and the CP points to the label of gap 3. When an available gap is needed, the search will start in group 0 from the current CP position.

[0345] If there are no available slots in the current group, address generator 2811 / 2821 pauses, the current group moves to the next group, and the CP moves to a tag pointing to the first slot in the new current group. In the next clock cycle, a search for an available slot begins at the CP position in the new current group. This process repeats in each subsequent clock cycle until an available slot is found. When an available slot is found in the current group, it is allocated, and the CP moves to the tag of the next slot. If the tag of the next slot is in the current group, the current group remains the current group. If the tag of the next slot is not in the current group, the group pointer (GP) is changed to point to the group containing the next slot.

[0346] Figure 38 and Figure 39 is a simple example illustrating a pseudo-FIFO tag replacement strategy. Figure 38 In the example, the tag bit for slot 5 indicates that the slot is available, the current group is group 0, and the CP points to the tag for slot 3. When an available slot is needed, the search begins in group 0 at the tag for slot 3. The search continues in consecutive slot order until the search determines that slot 5 is available. Slot 5 is dispatched, the CP moves to the tag pointing to slot 6, and the current group remains group 0. When another available slot is needed, the search begins in group 0 at tag 6.

[0347] exist Figure 39 In the example shown in Figure 2, the current group is group 0, the CP points to the label at gap 3, and there are no available gaps in group 0. When an available gap is needed, the search begins at the label at gap 3 in group 0. The search continues in consecutive gap order until the search determines that there are no available gaps in group 0. A stall is dispatched, the current group is set to group 1, and the CP moves to the label at gap 8, which points to the beginning of group 1. During the next clock cycle, a search is performed on group 1 for an available gap with the label at gap 8.

[0348] Figure 40 2 is a flow chart of a method for performing tag line replacement in a tagged memory system, which method may be performed by the stream engine 125, for example, as part of managing an array of tagged slots in the data storage 2816 / 2826. The method may be used to search for and allocate available slots or tag lines in the tagged memory system. It should be noted that both the CP and the GP operate in a cyclic or round-robin manner such that when the CP reaches the end of the final tag group, the GP moves to indicate the initial group, and the CP moves to the initial tag in that group.

[0349] Initially, the tag indicated by the CP is checked to determine 4000 whether the associated tag line is available for dispatch. If the tag indicates that the tag line is available, the tag line is dispatched 4002 to the address data, and the tag is modified to indicate that the tag line is dispatched. The CP is then moved 4003 to the tag pointing to the next tag line. If the end of the current tag group has not yet been reached 4004, the method ends. When the method is subsequently called, the GP indicates the same group as the previous call, and the CP points to the tag immediately after the tag of the previously dispatched tag line. If the end of the current tag group has been reached, the GP is set 4010 to the next group, and the method terminates. When the method is subsequently called, the GP indicates the next group, and the CP points to the initial tag in the group.

[0350] If the tag line associated with the tag indicated by the CP is not available 4000, the CP is moved 4006 to the tag of the next tag line. If the end of the current tag group has not yet been reached 4008, the availability of the tag line associated with the tag line indicated by the CP 4000 is checked. The process of searching for tags continues until an available tag line is found in the current tag group or the end of the tag group is reached 4008. If the end of the current group is reached before an available tag line is found, the GP is set 4010 to the next group and the method terminates. When the method is subsequently called, the GP indicates the next group and the CP points to the initial tag in the group.

[0351] In some examples of the above methods, rather than terminating the search for an available tag line upon reaching the end of a tag group, the search loops back to the beginning of the tag group and searches the remaining tags in the tag group until either an available tag line is found or the tag at the CP's original position when the search was initiated is reached. For example, suppose that when the search is initiated, the CP points to the tag for tag line 4 in group 0. Also suppose that tag lines 4–7 are unavailable in group 0. Rather than terminating the search upon reaching the tag for tag line 7, the search continues from the tag for tag line 0. If tag lines 0–3 are unavailable, the search terminates when the tag for tag line 4 is reached.

[0352] In some examples, a priority encoder search is used to search for tags in a group, where the priority of the tags is based on the position of the CP when the search is initiated. For example, if the CP points to the tag on tag line 4 when the search is initiated, the tag on tag line 6 has the highest priority, the tag on tag line 7 has the second highest priority, the tag on tag line 0 has the second highest priority, and so on. In addition, in general, the first available tag line in the group with the highest priority is selected for dispatch. Continuing with the previous example, if tag line 6 is available, tag line 6 is selected for dispatch. However, if tag line 6 is not available, but tag line 7 is available, tag line 7 is selected for dispatch. For example, the priority encoder is explained in more detail in the "Priority Encoder and Digital Encoder Tutorial" in the Electronics Tutorials available at https: / / www.electronics-tutorials.ws / combination / comb_4.html on August 30, 2019, which is incorporated herein by reference. In some examples, a priority encoder for tag line searching is implemented using combinational logic in memory dispatch and tracking 2814 / 2824.

[0353] Figure 41 and Figure 42 is an example illustrating a priority encoder search of available label lines. Figure 41 The priority of the tags in the group based on the value of CP is shown. For example, if CP points to the tag of tag line 4, the priority order is tag line 4, tag line 5, tag line 6, tag line 7, tag line 0, tag line 1, tag line 2 and tag line 3. Figure 42 The priority search mode is illustrated, assuming that CP points to the tag of tag line 4.

[0354] Figure 43 16 is a flow chart of a method for tag line replacement in a tagged memory system that can be performed by the stream engine 125, for example, as part of managing an array of tagged gaps in the data storage 2816 / 2826. The method (based on a priority encoder search) can be used to search for and assign available gaps or tag lines in a tagged memory system. Initially, the tags in the current group are tested 4300 by the priority encoder to determine if there are any available tag lines associated with any tags in the group. If there is at least one available tag line 4302, then the available tag lines are assigned 4304 based on the tag priority. As previously described herein, the priority of the tags is determined based on the CP when the search is initiated, and the highest priority available tag line is assigned.

[0355] The CP is then moved 4306 to the tag of the next tag line after the assigned tag line. If the end of the current group has been reached 4308, the GP is moved 4310 to the next group and the method terminates; otherwise, the GP is unchanged and the method terminates. If no tag lines are available 4302 in the current group, the CP and GP are moved 4312 to the next group and the method terminates.

[0356] In some examples, instead of using the priority encoder to search for labels for all tag lines in the current group at once, the priority encoder is used to search for labels from the CP to the end of the current group. If no available tag line is found, the remaining tags in the current group are searched. For example, if the CP points to the label for tag line 6, the first priority encoder search looks for labels for tag lines 6 and 7. If none of these tag lines are available, the priority encoder is used to search for labels for tag lines 0-5.

[0357] As previously described herein, in some examples, storage dispatch and tracking 2814 / 2824 may search two gaps or tag lines instead of one. If a priority encoder search is used, two available tag lines are searched in the group based on the priority of the tag. For example, if CP points to the tag of tag line 4, and tag lines 4, 6, and 7 are available, tag line 4 and tag line 6 are dispatched because these two tag lines have the highest priority of the available tag lines. In some examples, if there are not two tag lines in the current group, CP and GP are moved to the next group, and the next group is searched in the next clock cycle. In some examples, if only one tag line is available in the current group, that tag line is dispatched, and an available tag line in the next group is searched in the next clock cycle. Figure 44 is an example illustrating the priority search pattern within the current group when the CP points to the tag of tag line 4 and the search is for two available tag lines.

[0358] Figure 45 An example multi-processor system is described. In this example, SoC 4500 includes processor 100 ( Figure 1 ) (referred to as "processor A"), and is combined with a second processor 4511 (referred to as "processor B"). Each processor is coupled to a shared level 3 (L3) memory 4550 via bus 4551. Processor B includes an unshared L2 memory 4512. A direct memory access (DMA) engine 4560 can be programmed to transfer data / instruction blocks from the L3 memory to the L2 memory 130 or L2 memory 4512 using known or later developed DMA techniques. Various types of peripheral devices 4562 are also coupled to the memory bus 4551, such as wireless and / or wired communication controllers.

[0359] In this example, processor A, processor B, and L3 memory 4550 are all included in SoC 4500. SoC 4500 can be encapsulated to form a package that can be mounted on a substrate such as a printed circuit board (PCB) using known or later developed packaging technologies. For example, SoC 4500 can be encapsulated in a ball grid array (BGA) package. In this example, an external memory interface (EMI) 4552 allows processor A and / or processor B to access additional external mass storage 4554.

[0360] In this example, processor B is used for scalar processing and control functions. Processor. In other examples, various types of known or later developed processors may be combined with DSP 100. While two processors are illustrated in this example, in another example, multiple copies of DSP 100 and / or multiple copies of processor B may be included in the SoC and utilize the pseudo-FIFO tag line replacement strategy incorporated into stream engine 125 as described herein.

[0361] Other embodiments

[0362] While the disclosure has been described with respect to a limited number of embodiments, other embodiments can be devised which do not depart from the scope of the invention as disclosed herein.

[0363] For example, some embodiments have been described herein in which there are thirty-two tags, each tag being associated with a corresponding tag line, and the tags being divided into four groups of eight tags. In other embodiments, there may be more or fewer tags and tag lines, more or fewer groups, and / or more or fewer tags per group.

[0364] In another example, although the pseudo-FIFO replacement policy is described herein with reference to managing gaps in stream engine storage, the policy can be used in any memory system where tags are used to manage data storage in lines or gaps.

[0365] It is therefore contemplated that the appended claims will cover any such modifications of the embodiments as fall within the true scope of the disclosure.

Claims

1. A method for replacing a label line, the method comprising: Determine an available tag line among a plurality of tag lines of a tagged memory system by: Starting from the last dispatched label group among the plurality of non-overlapping label groups associated with the plurality of label lines: During one clock cycle, searching tags in the tag group for the available tag lines; and When no available tag line is found during the search in the tag group, tags in the next tag group of the plurality of non-overlapping tag groups are searched for the available tag line during the next clock cycle. 2 . The method of claim 1 , wherein searching for tags in the tag group begins with a tag in the tag group that immediately follows a tag associated with a tag line assigned in a previous search.

3. The method according to claim 1, wherein searching for tags in a tag group further comprises: An available label line is found, dispatched, and a pointer is set to the label associated with the next label line.

4. The method of claim 1, wherein the tagged memory system comprises thirty-two tag lines, each tag line having an associated tag, and each tag group comprises eight tags. The method of claim 1 , wherein the tagged memory system is included in a stream engine of a processor. The method of claim 1 , wherein a priority encoder is used to search for tags in each tag group.

7. The method of claim 1 , wherein searching for tags in a tag group further comprises searching for tags in the tag group for two available tag lines, and searching for tags in the next tag group further comprises searching the next tag group for two available tag lines when two available tag lines are not found during the search in the tag group.

8. A tagged memory system comprising: Multiple label lines; a plurality of tags, wherein each tag is associated with a corresponding tag line of the plurality of tag lines, and the plurality of tags are divided into non-overlapping tag groups; as well as A storage dispatch component is configured to perform pseudo first-in-first-out tag replacement, i.e., pseudo FIFO tag replacement, by: searching a tag group for an available tag line during a clock cycle based on a last dispatch that occurred in the tag group, and When no available tag line is found during the search in the tag group, a next tag group of the plurality of tag groups is searched for an available tag line during the next clock cycle.

9. The tagged memory system of claim 8, wherein searching the tag group begins with a tag in the tag group that immediately follows a tag associated with a tag line assigned in a previous search.

10. The tagged memory system of claim 8, wherein when an available tag line is found in the tag group, the tag line is dispatched and a pointer is set to a tag associated with the next tag line.

11. The tagged memory system of claim 8, wherein the plurality of tag lines comprises thirty-two tag lines, each tag line having an associated tag, and each tag group comprises eight tags.

12. The tagged memory system of claim 8, wherein the tagged memory system is included in a stream engine of a processor.

13. The tagged memory system of claim 8, wherein a priority encoder is used to search for tags in a tag group.

14. The tagged memory system of claim 8 , wherein the tag group is searched for two available tag lines during the clock cycle, and when the search in the tag group does not find two available tag lines, the next tag group is searched for two available tag lines during the next clock cycle.

15. A tagged memory system comprising: Multiple label lines; a plurality of tags, wherein each tag is associated with a corresponding tag line of the plurality of tag lines, and the plurality of tags are divided into non-overlapping tag groups; as well as A storage dispatch component is configured to search each of the plurality of tag groups in a round-robin order until an available tag line is located or all tag groups have been searched, wherein the search begins with a tag group that includes tags associated with a tag line dispatched in a previous search, and wherein each searched tag group is searched in a single clock cycle.

16. The tagged memory system of claim 15, wherein the storage dispatch component is further configured to search each tag group using a priority encoder.

17. The tagged memory system of claim 15, wherein the plurality of tag lines comprises thirty-two tag lines, each tag line having an associated tag, and each tag group comprises eight tags.

18. The tagged memory system of claim 15, wherein the tagged memory system is included in a stream engine of a processor.

19. The tagged memory system of claim 15, wherein the memory dispatch component is further configured to search each tag group for two available tag lines until two available tag lines are located in the same tag group or all tag groups have been searched.

20. The tagged memory system of claim 15, wherein the tagged memory system is included in a digital signal processor.

Images