stream engine with multi-dimensional cyclic addressing selectable in each dimension

Abstract

The invention relates to a stream engine with selectable multi-dimensional loop addressing in each dimension. A stream engine (125, 2700) for use in a digital data processor specifies a fixed read-only data stream defined by a plurality of nested loops. An address generator (1901) generates addresses of data elements of the nested loops. A stream head register (2718, 2728) stores a data element to be provided next to a functional unit for use as an operand. A stream template register (2800) independently specifies a linear address or a loop address pattern for each of the nested loops.

Description

[0001] This application is a divisional application of Chinese patent application 201711379621.5, filed on December 20, 2017, entitled "Streaming Engine with Selectable Multidimensional Circular Addressing in Each Dimension".

[0002] Related applications

[0003] This patent application is an improvement to U.S. Patent Application Serial No. 14 / 331,986, entitled "Highly Integrated Scalable, Flexible DSP MEGAMODULE ARCHITECTURE," filed July 15, 2014, which claims priority to U.S. Provisional Patent Application Serial No. 61 / 846,148, filed July 15, 2013. Technical Field

[0004] The technical field of this invention is digital data processing, and more specifically, the control of a streaming engine for operand retrieval. Background Technology

[0005] Modern digital signal processors (DSPs) face multiple challenges. Increasing workloads necessitate greater bandwidth. The size and complexity of system-on-a-chip (SoC) are constantly increasing. Memory system latency severely impacts certain types of algorithms. As transistors shrink, memory and registers become less reliable. As software stacks grow larger, the potential number of interactions and errors increases significantly.

[0006] Memory bandwidth and scheduling are issues for digital signal processors (DSPs) operating on real-time data. DSPs operating on real-time data typically receive an input data stream, perform filtering functions (such as encoding or decoding) on ​​the data stream, and output a transformed data stream. This system is called real-time because if the transformed data stream is unavailable for output at the scheduled time, the application fails. Typical video coding requires predictable but discontinuous patterns of input data. Given the available address generation and memory access resources, the corresponding memory access is often difficult to implement. A typical application requires memory access to load data registers from the data register file and then provide them to the functional units performing data processing. Summary of the Invention

[0007] This invention relates to a streaming engine used in digital signal processors. A fixed sequence of data streams is specified by storing corresponding parameters in a control register. The data stream comprises multiple nested loops. Once started, the data stream is read-only and cannot be written to. The functional unit using the streaming data has a first instruction type that reads only the data and a second instruction type that reads the data and advances the streaming engine. This typically corresponds to the needs of real-time filtering operations.

[0008] The stream engine includes an address generator that produces the addresses of data elements and a stream head register / stream head register that stores the data elements to be provided to functional units as operands. Each of the multiple nested loops has an independently specified linear addressing mode or a circular addressing mode with a specified loop block size.

[0009] The corresponding addressing mode and loop block size are specified by the corresponding fields in the stream definition template stored in the stream definition template register. This stream definition template also specifies other aspects of the predefined data stream, including data size and data type.

[0010] The preferred embodiment includes two independently defined data streams. The two data streams can be read or read / forwarded independently by a set of Very Long Instruction Word (VLIW) functional units. Attached Figure Description

[0011] These and other aspects of the invention are illustrated in the accompanying drawings, wherein:

[0012] Figure 1 A dual scalar / vector data path processor according to an embodiment of the present invention is shown;

[0013] Figure 2 It shows Figure 1 The registers and functional units in the dual scalar / vector data path processor are shown below;

[0014] Figure 3 The global scalar register file is shown;

[0015] Figure 4 The local scalar register file shared by the arithmetic function unit is shown;

[0016] Figure 5 The local scalar register file shared by the multiplication function unit is shown;

[0017] Figure 6 The local scalar register file shared by the load / store unit is shown;

[0018] Figure 7The global vector register file is shown;

[0019] Figure 8 The predicate register file is shown;

[0020] Figure 9 The local vector register stack shared by the arithmetic function unit is shown;

[0021] Figure 10 The local vector register file shared by the multiplication and related functional units is shown;

[0022] Figure 11 The pipeline stages of a central processing unit according to a preferred embodiment of the present invention are shown;

[0023] Figure 12 The instructions for a single retrieval package are shown;

[0024] Figure 13 An example of instruction encoding for the instructions used in this invention is shown;

[0025] Figure 14 The bit encoding of condition code extension slot 0 is shown;

[0026] Figure 15 The bit encoding of condition code extension slot 1 is shown;

[0027] Figure 16 The bit encoding of constant extended slot 0 is shown;

[0028] Figure 17 This is a partial block diagram showing the constant extension;

[0029] Figure 18 Carry control for SIMD operation according to the present invention is shown;

[0030] Figure 19 A conceptual diagram of the streaming engine of the present invention is shown;

[0031] Figure 20 This shows a first example of lane assignment in a vector;

[0032] Figure 21 A second example of channel allocation in a vector is shown;

[0033] Figure 22 A basic two-dimensional flow is shown;

[0034] Figure 23 It shows Figure 21 The order of elements within the example stream;

[0035] Figure 24This demonstrates how to extract a smaller rectangle from a larger rectangle;

[0036] Figure 25 This demonstrates how the streaming engine retrieves the stream of this example with a 4-byte transpose granularity;

[0037] Figure 26 This demonstrates how the streaming engine retrieves the stream of this example with an 8-byte transpose granularity;

[0038] Figure 27 Details of the streaming engine of the present invention are shown;

[0039] Figure 28 The stream template register of the present invention is shown;

[0040] Figure 29 The subfield definitions of the flag field of the stream template register of the present invention are shown;

[0041] Figure 30 The first alternative stream template register of the present invention, specified by the dimension format field, is shown;

[0042] Figure 31 The second alternative stream template register of the present invention, specified by the dimension format field, is shown;

[0043] Figure 32 The third alternative stream template register of the present invention, specified by the dimension format field, is shown;

[0044] Figure 33 The fourth alternative stream template register of the present invention, specified by the dimension format field, is shown;

[0045] Figure 34 The fifth alternative stream template register of the present invention, specified by the dimension format field, is shown;

[0046] Figure 35 A loop count selection circuit is shown, which is used to select the stream definition template bit of the loop count of multiple nested loops controlled by a dimension format field;

[0047] Figure 36 A loop dimension selection circuit is shown, which is used to select the flow definition template bit of the loop dimension of multiple nested loops controlled by the dimension format field;

[0048] Figure 37 An example of an adder control word circuit is shown, which generates an adder control word for a cyclic address generator that controls the selection of linear addressing mode and cyclic addressing mode.

[0049] Figure 38 This is a partial schematic diagram illustrating the address generation of nested loops according to the present invention.

[0050] Figure 39 A partial schematic diagram showing the flow engine supply of operands of the present invention is shown. Detailed Implementation

[0051] Figure 1 A dual scalar / vector data path processor according to a preferred embodiment of the present invention is shown. Processor 100 includes separate Level 1 instruction cache (L1I) 121 and Level 1 data cache (L1D) 123. Processor 100 includes a Level 2 combined instruction / data cache (L2) 130 that stores both instructions and data. Figure 1 The connection (bus 142) between the Level 1 instruction cache 121 and the Level 2 combination instruction / data cache 130 is shown. Figure 1 The connection (bus 145) between the Level 1 data cache 123 and the Level 2 combined instruction / data cache 130 is shown. In a preferred embodiment of the processor 100, the Level 2 combined instruction / data cache 130 stores both instructions for backing up the Level 1 instruction cache 121 and data for backing up the Level 1 data cache 123. In a preferred embodiment, the Level 2 combined instruction / data cache 130 is connected via... Figure 1 The components are further connected to higher-level caches and / or main memory in a manner not shown. In a preferred embodiment, the central processing unit core 110, the level 1 instruction cache 121, the level 1 data cache 123, and the level 2 combined instruction / data cache 130 are formed on a single integrated circuit. This single integrated circuit may optionally include other circuitry.

[0052] Central processing unit kernel 110 retrieves instructions from L1 instruction cache 121 under the control of instruction retrieval unit 111. Instruction retrieval unit 111 determines the next instruction to be executed and invokes an instruction set of the size of the retrieval packet. The nature and size of the retrieval packet are further detailed below. As is known in the art, in the event of a cache hit (if the instructions are stored in L1 instruction cache 121), the instructions are retrieved directly from L1 instruction cache 121. In the event of a cache miss (the specified instruction retrieval packet is not stored in L1 instruction cache 121), the instructions are searched for in L2 combined cache 130. In a preferred embodiment, the size of the cache line in L1 instruction cache 121 is equal to the size of the retrieval packet. The memory locations of these instructions are either hits or misses in L2 combined cache 130. Hits are served by L2 combined cache 130. Misses are served by higher-level caches (not shown) or by main memory (not shown). As is known in the art, the requested instructions can be provided to both the Level 1 instruction cache 121 and the central processing unit kernel 110 for accelerated use.

[0053] In a preferred embodiment of the invention, the central processing unit (CPU) core 110 includes multiple functional units that execute data processing tasks specified by instructions. An instruction dispatch unit 112 determines the target functional unit for each fetched instruction. In a preferred embodiment, the CPU 110 operates as a Very Long Instruction Word (VLIW) processor capable of simultaneously operating multiple instructions within a corresponding functional unit. Preferably, the compiler organizes instructions in execution packets executed together. The instruction dispatch unit 112 directs each instruction to its target functional unit. The functional unit assigned to an instruction is entirely specified by the compiler-generated instructions. The hardware of the CPU core 110 is not involved in this functional unit allocation. In a preferred embodiment, the instruction dispatch unit 112 can operate in parallel on multiple instructions. The number of such parallel instructions is set by the size of the execution packet, which will be described in further detail below.

[0054] Part of the task dispatching in instruction dispatch unit 112 determines whether execution occurs on a functional unit on the scalar data path side A 115 or the vector data path side B 116. An instruction bit, referred to as the s-bit in each instruction, determines which data path is controlled by the instruction. This will be described in further detail below.

[0055] Instruction decoding unit 113 decodes each instruction in the current execution package. Decoding includes identifying the functional unit executing the instruction, identifying registers in the possible register file that provide data for the corresponding data processing operation, and identifying the register destination of the result of the corresponding data processing operation. As further explained below, an instruction may include a constant field that replaces an operand field of a register number. The result of this decoding is a signal used to control the target functional unit to perform the data processing operation specified by the corresponding instruction on the specified data.

[0056] The central processing unit core 110 includes a control register 114. The control register 114 stores information for controlling the functional units in the scalar data path side A 115 and the vector data path side B 116 in a manner unrelated to this invention. This information may include mode information, etc.

[0057] The decoded instruction from instruction decoder 113 and the information stored in control register 114 are provided to scalar data path side A 115 and vector data path side B 116. As a result, functional units within scalar data path side A 115 and vector data path side B 116 perform instruction-specified data processing operations on the instruction-specified data and store the results in one or more instruction-specified data registers. Each of scalar data path side A 115 and vector data path side B 116 includes multiple functional units preferably operating in parallel. These will be combined below. Figure 2 Further details. A data path 117 exists between the scalar data path side A 115 and the vector data path side B 116, allowing data exchange.

[0058] The central processing unit (CPU) core 110 further includes non-instruction-based modules. Emulation unit 118 allows the determination of the machine state of the CPU core 110 in response to instructions. This functionality is typically used for algorithm development. Interrupt / Exception unit 119 enables the CPU core 110 to respond to external asynchronous events (interrupts) and to respond to attempts to perform incorrect operations (exceptions).

[0059] The central processing unit core 110 includes a stream engine 125. The stream engine 125 provides two data streams from predetermined addresses, typically cached in a L2 combined cache 130, to the register file of the vector data path side B. This provides control data movement directly from memory (such as in the cache in the L2 combined cache 130) to the function unit operand inputs. This is further described below.

[0060] Figure 1An exemplary data width of the bus between the various parts is shown. The Level 1 instruction cache 121 provides instructions to the instruction fetch unit 111 via bus 141. Bus 141 is preferably a 512-bit bus. Bus 141 is unidirectional from the Level 1 instruction cache 121 to the central processing unit core 110. The Level 2 combined cache 130 provides instructions to the Level 1 instruction cache 121 via bus 142. Bus 142 is preferably a 512-bit bus. Bus 142 is unidirectional from the Level 2 combined cache 130 to the Level 1 instruction cache 121.

[0061] Level 1 data cache 123 exchanges data with the register file in scalar data path side A 115 via bus 143. Bus 143 is preferably a 64-bit bus. Level 1 data cache 123 exchanges data with the register file in vector data path side B 116 via bus 144. Bus 144 is preferably a 512-bit bus. Buses 143 and 144 are shown to bidirectionally support both data reads and writes to the central processing unit core 110. Level 1 data cache 123 exchanges data with Level 2 combined cache 130 via bus 145. Bus 145 is preferably a 512-bit bus. Bus 145 is shown to provide bidirectional support for cache services for both data reads and writes to the central processing unit core 110.

[0062] The L2 combined cache 130 provides data from a first data stream to the streaming engine 125 via bus 146. Bus 146 is preferably a 512-bit bus. The streaming engine 125 provides the data from the first data stream to the functional unit of the vector data path side B 116 via bus 147. Bus 147 is preferably a 512-bit bus. The L2 combined cache 130 provides data from a second data stream to the streaming engine 125 via bus 148. Bus 148 is preferably a 512-bit bus. The streaming engine 125 provides the data from the second data stream to the functional unit of the vector data path side B 116 via bus 149. Bus 149 is preferably a 512-bit bus. According to a preferred embodiment of the invention, buses 146, 147, 148, and 149 are shown as unidirectional from the L2 combined cache 130 to the streaming engine 125 and the vector data path side B 116.

[0063] In a preferred embodiment of the invention, according to U.S. Patent No. 6,606,686 entitled "Unified Memory System Architecture Including Cache and Directly Addressable Static Random Access Memory", both the Level 1 data cache 123 and the Level 2 combined cache 130 can be configured as a selected number of caches or directly addressable memory.

[0064] Figure 2 Further details of the functional units and register files within scalar data path side A 115 and vector data path side B 116 are shown. Scalar data path side A 115 includes a global scalar register file 211, an L1 / S1 local register file 212, an M1 / N1 local register file 213, and a D1 / D2 local register file 214. Scalar data path side A 115 includes L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226. Vector data path side B 116 includes a global vector register file 231, an L2 / S2 local register file 232, an M2 / N2 / C local register file 233, and an assertion register file 234. Vector data path side B 116 includes L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246. There are restrictions on which functional units can read from or write to which register files. These will be detailed below.

[0065] The scalar data path side A 115 includes an L1 unit 221. The L1 unit 221 typically accepts two 64-bit operands and produces a 64-bit result. Each operand is retrieved from an instruction-specified register in either the global scalar register file 211 or the L1 / S1 local register file 212. The L1 unit 221 preferably performs the following instruction selection operations: 64-bit addition / subtraction operations; 32-bit minimum / maximum operations; 8-bit Single Instruction Multiple Data (SIMD) instructions, such as summation of absolute values, determination of minimum and maximum values; looping minimum / maximum operations; and various move operations between register files. The result can be 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.

[0066] The scalar data path side A 115 includes an S1 unit 222. The S1 unit 222 typically accepts two 64-bit operands and produces a 64-bit result. Each operand is retrieved from an instruction specifying register in either the global scalar register file 211 or the L1 / S1 local register file 212. The S1 unit 222 preferably performs the same type of operation as the L1 unit 221. Slight variations may optionally exist between the data processing operations supported by the L1 unit 221 and the S1 unit 222. The result may be written to an instruction specifying 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.

[0067] The scalar data path side A 115 includes M1 unit 223. M1 unit 223 typically accepts two 64-bit operands and produces a 64-bit result. Each operand is retrieved from an instruction-specified register in either the global scalar register file 211 or the M1 / N1 local register file 213. M1 unit 223 preferably performs the following instruction selection operations: 8-bit multiplication; complex point product; 32-bit bit counting; complex conjugate multiplication; bitwise logical operations; shift, addition, and subtraction. The result can be written to an instruction-specified register in either 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.

[0068] The scalar data path side A 115 includes N1 unit 224. N1 unit 224 typically accepts two 64-bit operands and produces a 64-bit result. Each operand is retrieved from an instruction specifying register in either the global scalar register file 211 or the M1 / N1 local register file 213. N1 unit 224 preferably performs the same type of operation as M1 unit 223. There may be dual operations (referred to as dual-issue instructions) that use both M1 unit 223 and N1 unit 224. The result may be written to an instruction specifying register in either 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.

[0069] The scalar data path side A 115 includes D1 unit 225 and D2 unit 226. D1 unit 225 and D2 unit 226 typically each accept two 64-bit operands and each 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 load and store. D2 unit 226 is used for 512-bit vector load and store. D1 unit 225 and D2 unit 226 also preferably perform: data exchange, packing, and unpacking for load and store; 64-bit SIMD arithmetic operations; and 64-bit bitwise logic operations. The D1 / D2 local register file 214 typically stores the base address and offset address used in the address calculations for the corresponding load and store operations. Each operand is retrieved from the instruction-specified register in either the global scalar register file 211 or the D1 / D2 local register file 214. The calculation results can be written to the instruction-specified registers of 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.

[0070] The vector data path side B 116 includes an L2 unit 241. The L2 unit 221 typically accepts two 512-bit operands and produces a 512-bit result. Each operand is retrieved from an instruction specifying register in the global vector register file 231, the L2 / S2 local register file 232, or the assertion register file 234. In addition to the wider 512-bit data, the L2 unit 241 preferably executes instructions similar to those in the L1 unit 221. The result can be written to an instruction specifying register in the global vector register file 231, the L2 / S2 local register file 222, the M2 / N2 / C local register file 233, or the assertion register file 234.

[0071] The vector data path side B 116 includes an S2 unit 242. The S2 unit 242 typically accepts two 512-bit operands and produces a 512-bit result. Each operand is retrieved from an instruction specifying register in the global vector register file 231, the L2 / S2 local register file 232, or the assertion register file 234. In addition to the wider 512-bit data, the S2 unit 242 preferably executes instructions similar to those of the S1 unit 222. The result can be written to the instruction specifying register in the global vector register file 231, the L2 / S2 local register file 222, the M2 / N2 / C local register file 233, or the assertion register file 234. There can be dual operations (referred to as dual-issue instructions) that use both the L2 unit 241 and the S2 unit 242. The result can be written to the instruction specifying register in the global vector register file 231, the L2 / S2 local register file 232, or the M2 / N2 / C local register file 233.

[0072] The vector data path side B 116 includes an M2 unit 243. The M2 unit 243 typically accepts two 512-bit operands and produces a 512-bit result. Each operand is retrieved from an instruction specifying register in either the global vector register file 231 or the M2 / N2 / C local register file 233. In addition to the wider 512-bit data, the M2 unit 243 preferably executes instructions similar to those in the M1 unit 222. The result can be written to an instruction specifying register in either the global vector register file 231, the L2 / S2 local register file 232, or the M2 / N2 / C local register file 233.

[0073] The vector data path side B 116 includes an N2 unit 244. The N2 unit 244 typically accepts two 512-bit operands and produces a 512-bit result. Each operand is retrieved from an instruction specifying register in either the global vector register file 231 or the M2 / N2 / C local register file 233. The N2 unit 244 preferably performs the same type of operation as the M2 unit 243. There may be dual operations (referred to as dual-issue instructions) that are used together with both the M2 unit 243 and the N2 unit 244. The result may be written to an instruction specifying register in either the global vector register file 231, the L2 / S2 local register file 232, or the M2 / N2 / C local register file 233.

[0074] The vector data path side B 116 includes a C unit 245. The C unit 245 typically accepts two 512-bit operands and produces a 512-bit result. Each operand is retrieved from an instruction-specified register in either the global vector register file 231 or the M2 / N2 / C local register file 233. The C unit 245 preferably executes: "rake" and "search" instructions; up to 512 2-bit PN * 8-bit multiplications of I / Q complex numbers per clock cycle; calculations of 8-bit and 16-bit absolute sum of differences (SADs), up to 512 SADs per clock cycle; horizontal addition and horizontal minimum / maximum instructions; and vector permutation indicators. The C unit 245 also includes four vector control registers (CUCR0 through CUCR3) for controlling certain operations of the C unit 245 instructions. In some C unit 245 operations, control registers CUCR0 through CUCR3 are used as operands. Preferably, control registers CUCR0 to CUCR3 are used to control the general permutation instruction (VPERM) and to serve as masks for SIMD multiple DOT (dot) product operations (DOTPM) and SIMD multiple absolute difference sums (SAD) operations. Control register CUCR0 is preferably used to store the polynomial for the Galois field multiply operation (GFMPY). Control register CUCR1 is preferably used to store the Galois field polynomial generator function.

[0075] The vector data path side B 116 includes a P unit 246. The P unit 246 performs basic logical operations on the registers of the local assertion register file 234. The P unit 246 has direct access to read and write to the assertion register file 234. These operations include AND, ANDN, OR, XOR, NOR, BITR, NEG, SET, BITCNT, RMBD, BIT Decimate, and Expand. The generally intended use of the P unit 246 includes operations on the results of SIMD vector comparisons used to control another SIMD vector operation.

[0076] Figure 3 Global scalar register file 211 is shown. There are 16 independent 64-bit wide scalar registers, labeled A0 to A15. Each register in global scalar register file 211 can be read or written as 64-bit scalar data. All scalar data path 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 or write global scalar register file 211. Global scalar register file 211 can be read as 32 bits or 64 bits, and can only be written as 64 bits. Instruction execution determines the size of the data to be read. Under the limitations described in detail below, vector data path 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 global scalar register file 211 via cross path 117.

[0077] Figure 4 The D1 / D2 local register file 214 is shown. It contains 16 independent 64-bit wide scalar registers, labeled D0 to D16. Each register in the D1 / D2 local register file 214 can be read from or written as 64-bit scalar data. All scalar data path-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can be written to the global scalar register file 211. Only D1 unit 225 and D2 unit 226 can be read from the D1 / D2 local scalar register file 214. The data stored in the D1 / D2 local scalar register file 214 is expected to include the base address and offset address used in address calculations.

[0078] Figure 5 The L1 / S1 local register file 212 is shown. Figure 5 The illustrated embodiment has eight independent 64-bit wide scalar registers, labeled AL0 through AL7. Preferred instruction encoding (see...) Figure 13 This allows the L1 / S1 local register file 212 to include up to 16 registers. Figure 5 The embodiment implements only 8 registers to reduce circuit size and complexity. Each register in the L1 / S1 local register file 212 can be read from or written as 64-bit scalar data. All scalar data path-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can be written to the L1 / S1 local scalar register file 212. Only L1 unit 221 and S1 unit 222 can be read from the L1 / S1 local scalar register file 212.

[0079] Figure 6 The M1 / N1 local register file 213 is shown. Figure 6 The illustrated embodiment has eight independent 64-bit wide scalar registers, labeled AM0 through AM7. Preferred instruction encoding (see...) Figure 13 This allows the M1 / N1 local register file 213 to include up to 16 registers. Figure 6 The embodiment implements only 8 registers to reduce circuit size and complexity. Each register in the M1 / N1 local register file 213 can be read from or written as 64-bit scalar data. All scalar data path-side A115 functional units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can be written to the M1 / N1 local scalar register file 213. Only M1 unit 223 and N1 unit 224 can be read from the M1 / N1 local scalar register file 213.

[0080] Figure 7 Global vector register file 231 is shown. It contains 16 independent 512-bit wide scalar registers. Each register in global vector register file 231 can be read or written as 64-bit scalar data labeled B0 through B15. Each register in global vector register file 231 can be read or written as 512-bit vector data labeled VB0 through VB15. The instruction type determines the data size. All vector data path side B 116 function units (L2 unit 241, S2 unit 242, M3 unit 243, N2 unit 244, C unit 245, and P unit 246) can read or write global scalar register file 231. Subject to the limitations detailed below, scalar data path side A 115 function units (L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226) can read from global vector register file 231 via cross path 117.

[0081] Figure 8The P local register file 234 is shown. It has eight independent 64-bit wide registers, labeled P0 through P15. Each register in the P local register file 234 can be read or written as 64-bit scalar data. The vector data path side B 116 functional units L2 unit 241, S2 unit 242, C unit 244, and P unit 246 can write to the P local register file 234. Only L2 unit 241, S2 unit 242, and P unit 246 can be read from the P local scalar register file 234. Common intended uses of the P local register file 234 include: writing a single bit of a SIMD vector comparison result from L2 unit 241, S2 unit 242, or C unit 244; operations performed by P unit 246 on the SIMD vector comparison result; and using the operation result to control another SIMD vector operation.

[0082] Figure 9 The L2 / S2 local register file 232 is shown. Figure 9 The illustrated embodiment has eight independent scalar registers, each 512 bits wide. Preferred instruction encoding (see...) Figure 13 This allows the L2 / S2 local register file 232 to include up to 16 registers. Figure 9 The embodiment implements only 8 registers to reduce circuit size and complexity. Each register in the L2 / S2 local vector register file 232 can be read or written as 64-bit scalar data labeled BL0 to BL7. Each register in the L2 / S2 local vector register file 232 can be read or written as 512-bit vector data labeled VBL0 to VBL7. The instruction type determines the data size. All vector data path-side B 116 functional units (L2 unit 241, S2 unit 242, M2 unit 233, N2 unit 244, C unit 245, and P unit 246) can be written to the L2 / S2 local vector register file 232. Only L2 unit 241 and S2 unit 242 can be read from the L2 / S2 local vector register file 232.

[0083] Figure 10 The M2 / N2 / C local register file 233 is shown. Figure 10 The illustrated embodiment has eight independent 512-bit wide scalar registers. Preferred instruction encoding (see [link]). Figure 13 This allows the L1 / S1 local register file 212 to include up to 16 registers. Figure 10The embodiment implements only 8 registers to reduce circuit size and complexity. Each register in the M2 / N2 / C local vector register file 233 can be read or written as 64-bit scalar data labeled BM0 to BM7. Each register in the M2 / N2 / C local vector register file 233 can be read or written as 512-bit vector data labeled VBM0 to VBM7. All vector data path-side B 116 functional units (L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246) can be written to the M2 / N2 / C local vector register file 233. Only M2 unit 233, N2 unit 244, and C unit 245 can be read from the M2 / N2 / C local vector register file 233.

[0084] Providing a global register file accessible to all functional units on one side and a local register file accessible to only some functional units on one side is a design choice. This invention can be implemented using only one type of register file corresponding to the disclosed global register file.

[0085] Cross path 117 allows limited data exchange between scalar data path side A 115 and vector data path side B 116. During each operating cycle, a 64-bit data word can be called from global scalar register file A 211 as an operand for one or more functional units on vector data path side B 116, and a 64-bit data word can be called from global vector register file 231 as an operand for one or more functional units on scalar data path side A 115. Any functional unit on scalar data path side A 115 (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. This 64-bit operand is the least significant bit of the 512-bit data in the accessed register of global vector register file 232. Multiple scalar data path side A 115 functional units can use the same 64-bit cross-path data as operands during the same operation cycle. However, in any single operation cycle, only one 64-bit operand is transferred from the vector data path side B 116 to the scalar data path side A 115. Any vector data path side B 116 functional unit (L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, C unit 245, and P unit 246) can read the 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 any other 64-bit operand. If the corresponding instruction is a vector instruction, the high 448 bits of the operand are filled with zeros. Multiple vector data path side B 116 functional units can use the same 64-bit cross-path data as operands during the same operation cycle. In any single operation cycle, only one 64-bit operand is transferred from the scalar data path side A 115 to the vector data path side B 116.

[0086] Streaming engine 125 transmits data under certain constraints. Streaming engine 125 controls two data streams. Each stream consists of a sequence of elements of a specific type. Programs operating on the streams read the data sequentially and operate on each element sequentially. Each stream has the following basic properties: Stream data has a well-defined start and end time. Stream data has a fixed element size and type throughout the stream. Stream data has a fixed sequence of elements. Therefore, programs cannot randomly search within the stream. Stream data is read-only while active. Programs cannot write to the stream while reading from it. Once a stream is opened, streaming engine 125: calculates the address; retrieves the defined data type from the secondary unified cache (which may require cache services from higher-level memory); performs data type operations such as zero extension, sign extension, and data element sorting / swapping such as matrix transformations; and directly passes the data to the programmed data register file within the central processing unit core 110. Therefore, streaming engine 125 is useful for real-time digital filtering operations on well-performing data. The streaming engine 125 releases these memory retrieval tasks from the corresponding central processing unit kernel 110, thereby enabling other processing functions.

[0087] The streaming engine 125 provides the following benefits: Streaming engine 125 allows for multidimensional memory access. Streaming engine 125 increases the available bandwidth of functional units. Because the streaming buffer bypasses the L1 data cache 123, streaming engine 125 minimizes the number of cache miss pauses. Streaming engine 125 reduces the number of scalar operations required to maintain loops. Streaming engine 125 manages address pointers. Streaming engine 125 handles address generation, automatically releasing address generation instruction slots and D1 units 224 and D2 units 226 for other computations.

[0088] The central processing unit kernel 110 operates on an instruction pipeline. Instructions are fetched from fixed-length instruction packets, as described further below. All instructions require the same number of pipeline stages for fetching and decoding, but the number of execution stages varies.

[0089] Figure 11 The following pipeline stages are illustrated: program retrieval stage 1110, dispatch and decode stage 1110, and execution stage 1130. Program retrieval stage 1110 comprises three stages for all instructions. Dispatch and decode stage comprises three stages for all instructions. Execution stage 1130 comprises one to four stages depending on the instruction.

[0090] The retrieval phase 1110 includes a program address generation phase 1111 (PG), a program access phase 1112 (PA), and a program reception phase 1113 (PR). During the program address generation phase 1111 (PG), the program address is generated in the central processing unit kernel 110, and a read request is sent to the memory controller of the L1 instruction cache. During the program access phase 1112 (PA), the L1 instruction cache processes the request, accesses the data in its memory, and sends a retrieval packet to the boundary of the central processing unit kernel 110. During the program reception phase 1113 (PR), the central processing unit kernel 110 registers the retrieval packet.

[0091] The instruction always retrieves 16 32-bit wide slots, forming a retrieval packet at a time. Figure 12 The diagram illustrates 16 instructions 1201 to 1216 in a single fetch packet. The fetch packet is aligned on 512-bit (16-word) boundaries. A preferred embodiment employs a fixed 32-bit instruction length. Fixed-length instructions are advantageous for several reasons. Fixed-length instructions enable simple decoder alignment. Properly aligned instruction fetches allow multiple instructions to be loaded into a parallel instruction decoder. This proper alignment of instruction fetches can be achieved through predetermined instruction alignment when stored in memory coupled to fixed-length instruction packet fetches (fetch packets aligned on 512-bit boundaries). Aligned instruction fetches allow the parallel decoder to operate on fetch bits of the instruction size. Variable-length instructions require initial steps to locate each instruction boundary before they can be decoded. Fixed-length instruction sets generally allow for a more regular layout of instruction fields. This simplifies the construction of each decoder, which is advantageous for widely distributed VLIW CPUs.

[0092] The execution of each instruction is partially controlled by a p-bit in each instruction. This p-bit is preferably bit 0 of a 32-bit wide slot. The p-bit determines whether an instruction is executed in parallel with the next instruction. Instructions are scanned from lower to higher memory addresses. If the p-bit of an instruction is 1, the next instruction (at a higher memory address) is executed in parallel with it (within the same cycle as the instruction). If the p-bit of an instruction is 0, the next instruction is executed in the cycle following the instruction.

[0093] The central processing unit core 110 and the L1 instruction cache 121 pipeline are decoupled. The return of a fetch packet from the L1 instruction cache can take a different number of clock cycles, depending on external conditions such as whether a hit occurs in the L1 instruction cache 121 or in the L2 combined cache 130. Therefore, program access phase 1112 (PA) may require several clock cycles instead of one clock cycle as in other phases.

[0094] Instructions executed in parallel constitute an execution package. In a preferred embodiment, an execution package may include up to sixteen instructions. No two instructions in an execution package may use the same functional unit. Slots are of one of five types: 1) self-contained instructions that execute on one of the 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) of the central processing unit kernel 110; 2) unitless instructions, such as NOP (no operation) instructions or multiple NOP instructions; 3) branch instructions; 4) field extensions of constants; and 5) conditional code extensions. Some of these slot types will be explained further below.

[0095] The scheduling and decoding phase 1110 includes an instruction dispatch to the appropriate execution unit phase 1121 (DS), an instruction pre-decoding phase 1122 (D1), and an instruction decoding and operand fetch phase 1222 (D2). During the instruction dispatch to the appropriate execution unit phase 1121 (DS), the fetch packet is divided into execution packets and assigned to the appropriate functional unit. During the instruction pre-decoding phase 1122 (D1), the source register, destination register, and associated path are decoded to execute the instruction in the functional unit. During instruction decoding, the operand fetch phase 1222 (D2) performs unit decoding in more detail and reads operands from the register file.

[0096] Execution phase 1130 includes execution phases 1131 to 1135 (E1 to E5). Different types of instructions require different numbers of these phases to complete execution. These pipeline phases play an important role in understanding the device state at the cycle boundaries of the central processing unit core 110.

[0097] During execution phase 1131 (E1), the conditions of the instruction are evaluated and the operands are operated on. For example... Figure 11 As shown, execution stage 1131 can receive operands from one of the stream buffer 1141 and the register file, schematically shown as 1142. For load and store instructions, address generation is performed and the address modification is written to the register file. For branch instructions, the branch fetch packet of stage PG is affected. Figure 11 As shown, load and store instruction accesses memory here are schematically represented as memory 1151. For a single-cycle instruction, the result is written to the destination register file. This assumes that any condition of the instruction is evaluated as true. If the condition is evaluated as false, the instruction does not write any result or have any pipelined operation after executing stage 1131.

[0098] During the execution of a 2-stage 1132 (E2) instruction, a load instruction sends the address to memory. A store instruction sends both the address and data to memory. A single-cycle instruction that results in saturation sets the SAT bit in the Control Status Register (CSR) when saturation occurs. For two-cycle instructions, the result is written to the destination register file.

[0099] During the execution of the 3-stage 1133 (E3), data memory accesses are performed. Any multiplication instructions with saturated results set the SAT bit in the Control Status Register (CSR) when saturation occurs. For instructions that run for 3 cycles, the result is written to the destination register file.

[0100] During the execution of stage 4 1134 (E4), the load instruction brings data to the boundary of the central processing unit core 110. For 4 cycles of instructions, the result is written to the destination register file.

[0101] During the execution of stage 5 1135 (E5), the load instruction writes data to the register. This is in Figure 11 The diagram schematically illustrates the input from memory 1151 to execution stage 1135.

[0102] Figure 13 An example of instruction encoding 1300 for the functional unit instructions used in this invention is shown. Those skilled in the art will recognize that other instruction encodings are feasible and within the scope of this invention. Each instruction consists of 32 bits and controls the operation of one of the individually 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). The bit fields are defined as follows.

[0103] The creg field 1301 (bits 29 to 31) and z bit 1302 (bit 28) are optional fields used in conditional instructions. These bits are used by conditional instructions to identify assertion registers and conditions. z bit 1302 (bit 28) indicates whether the prediction is based on zero or non-zero in the assertion register. If z = 1, the test is used for equations with zero. If z = 0, the test is used for non-zero. The cases of creg = 0 and z = 0 are considered always true to allow unconditional instruction execution. The creg field 1301 and z field 1302 are encoded in the instruction as shown in Table 1.

[0104]

[0105] Table 1

[0106] The execution of a conditional instruction depends on a value stored in a designated data register. This data register is located in global scalar register file 211, which is used for all functional units. Note that "z" in the z-bit column refers to the zero / non-zero comparison selection described above, and "x" is an irrelevant state. This encoding can only designate a subset of the 16 global registers as assertion registers. This selection is to preserve bits in the instruction encoding. Note that unconditional instructions do not have these optional bits. For unconditional instructions, these bits in fields 1301 and 1302 (28 to 31) are preferably used as additional opcode bits.

[0107] The dst field 1303 (bits 23 to 27) specifies the corresponding register in the register file as the destination of the instruction result.

[0108] The src2 / cst field 1304 (bits 18 to 22) has several meanings based on the instruction opcode field (bits 4 to 12 for all instructions and additional bits 28 to 31 for unconditional instructions). The first meaning is to designate the register in the corresponding register file as the second operand. The second meaning is a direct constant. Depending on the instruction type, this is treated as an unsigned integer with zeros extended to the specified data length, or as a signed integer with the sign extended to the specified data length.

[0109] The src1 field 1305 (bits 13 to 17) specifies the register in the corresponding register file as the first source operand.

[0110] The opcode field 1306 (bits 4 to 12) of all instructions (and additional bits 28 to 31 for unconditional instructions) specifies the type of instruction and the appropriate instruction options. This includes explicit specification of the functional unit used and the operation performed. A detailed explanation of the opcodes beyond the instruction options detailed below is beyond the scope of this invention.

[0111] Bit 1307 (bit 2) is used only for direct constant instructions that can expand constants. If e = 1, the direct constant is expanded as detailed below. If e = 0, the direct constant is not expanded. In this case, the direct constant is specified by field 1304 (bits 18 to 22) of src2 / cst. Note that this bit 1307 is only used for certain instructions. Therefore, with proper encoding, bit 1307 can be omitted from instructions that do not require it, and this bit is used as an additional opcode bit.

[0112] Bit 1307 (bit 1) specifies either scalar data path side A 115 or vector data path side B 116. If s = 0, scalar data path side A 115 is selected. This limits the functional unit to... Figure 2The L1 unit 221, S1 unit 222, M1 unit 223, N1 unit 224, D1 unit 225, and D2 unit 226, along with their corresponding register files, are shown. Similarly, s = 1 selects the vector data path side B 116, restricting the functional unit to... Figure 2 The L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, P unit 246 and their corresponding register files are shown.

[0113] Bit p (1308, bit 0) marks the execution packet. Bit p determines whether an instruction is executed concurrently with the following instructions. Bit p is scanned from low to high address. If p = 1 for the current instruction, the next instruction is executed concurrently with the current instruction. If p = 0 for the current instruction, the next instruction is executed in the cycle following the current instruction. All concurrently executed instructions constitute an execution packet. An execution packet can contain up to twelve instructions. Each instruction in an execution packet must use a different functional unit.

[0114] There are two distinct condition code extension slots. Each execution package may include each of these unique 32-bit condition code extension slots, which includes the 4-bit creg / z field of the instructions in the same execution package. Figure 14 The encoding of condition code extension slot 0 is shown, and Figure 15 This shows the encoding of condition code extension slot 1.

[0115] Figure 14This shows the encoding of the 32-bit condition code extension slot 0. Field 1401 (bits 28 to 31) specifies the 4 creg / z bits allocated to the L1 unit 221 instruction in the same execution package. Field 1402 (bits 27 to 24) specifies the 4 creg / z bits allocated to the L2 unit 241 instruction in the same execution package. Field 1403 (bits 19 to 23) specifies the 4 creg / z bits allocated to the S1 unit 222 instruction in the same execution package. Field 1404 (bits 16 to 19) specifies the 4 creg / z bits allocated to the S2 unit 242 instruction in the same execution package. Field 1405 (bits 12 to 15) specifies the 4 creg / z bits allocated to the D1 unit 225 instruction in the same execution package. Field 1406 (bits 8 to 11) specifies the 4 creg / z bits allocated to the D2 unit 226 instruction in the same execution package. Field 1407 (bits 6 and 7) is unused / reserved. Field 1408 (bits 0 to 5) is encoded as a unique set of bits (CCEX0) to identify condition code extension slot 0. Once this unique ID of condition code extension slot 0 is detected, the corresponding creg / z bits are used to control the conditional execution of any L1 unit 221, L2 unit 241, S1 unit 222, S2 unit 242, D1 unit 225, and D2 unit 226 instructions within the same execution package. The interpretation of these creg / z bits is shown in Table 1. If the corresponding instruction is conditional (including the creg / z bits), the corresponding bit in condition code extension slot 0 overrides the condition code bit in the instruction. Note that an execution package cannot have more than one instruction pointing to a specific execution unit. An instruction's execution package cannot contain more than one condition code extension slot 0. Therefore, the mapping of creg / z bits to function unit instructions is explicit. Setting the creg / z bit to "0000" will make the instruction unconditional. Therefore, a properly encoded condition code extension slot 0 can make some corresponding instructions conditional and make some instructions unconditional.

[0116] Figure 15This shows the encoding of condition code extension slot 1 with 32 bits. Field 1501 (bits 28 to 31) specifies the 4 creg / z bits allocated to instruction 223 in unit M1 within the same execution package. Field 1502 (bits 27 to 24) specifies the 4 creg / z bits allocated to instruction 243 in unit M2 within the same execution package. Field 1503 (bits 19 to 23) specifies the 4 creg / z bits allocated to instruction 245 in unit C within the same execution package. Field 1504 (bits 16 to 19) specifies the 4 creg / z bits allocated to instruction 224 in unit N1 within the same execution package. Field 1505 (bits 12 to 15) specifies the 4 creg / z bits allocated to instruction 244 in unit N2 within the same execution package. Field 1506 (bits 5 to 11) is unused / reserved. Field 1507 (bits 0 to 5) is encoded as a unique set of bits (CCEX1) to identify condition code extension slot 1. Once this unique ID of condition code extension slot 1 is detected, the corresponding creg / z bits are used to control the conditional execution of any instructions in M1 unit 223, M2 unit 243, C unit 245, N1 unit 224, and N2 unit 244 within the same execution package. The interpretation of these creg / z bits is shown in Table 1. If the corresponding instruction is conditional (including the creg / z bits), the corresponding bit in condition code extension slot 1 overrides the condition code bit in the instruction. Note that an execution package cannot have more than one instruction pointing to a specific execution unit. An instruction's execution package cannot contain more than one condition code extension slot 1. Therefore, the mapping of creg / z bits to function unit instructions is explicit. Setting the creg / z bit to "0000" makes the instruction unconditional. Therefore, a properly encoded condition code extension slot 1 can make some instructions conditional and others unconditional.

[0117] Both condition code extension slot 0 and condition code extension slot 1 can include p bits to define the combination as described above. Figure 13 The aforementioned execution package. In a preferred embodiment, such as... Figure 14 and Figure 15 As shown, code extension slot 0 and condition code extension slot 1 preferably have bit 0 (p bits) that are always encoded as 1. Therefore, neither condition code extension slot 0 nor condition code extension slot 1 can be located in the last instruction slot of the execution packet.

[0118] There are two distinct constant extension slots. Each execution packet may include each of these unique 32-bit constant extension slots, which includes 27 bits to be concatenated as higher-order bits with the 5-bit constant field 1305 to form a 32-bit constant. As noted in the instruction encoding description above, only some instructions define the src2 / cst field 1304 as a constant instead of a source register identifier. At least some of these instructions can use the constant extension slot to extend this constant to 32 bits.

[0119] Figure 16 The fields of constant extension slot 0 are shown. Each execution package may include one instance of constant extension slot 0 and one instance of constant extension slot 1. Figure 16 The constant extension slot 0 1600 is shown to include two fields. Field 1601 (bits 5 to 31) constitutes the most significant 27 bits of the extended 32-bit constant, which includes the target instruction scr2 / cst field 1304 as the five least significant bits. Field 1602 (bits 0 to 4) is encoded as a unique set of bits (CSTX0) to identify constant extension slot 0. In a preferred embodiment, constant extension slot 0 1600 can only be used to extend the constant of one of the following instructions in the same execution package: L1 unit 221 instruction, D1 unit 225 instruction, S2 unit 242 instruction, D2 unit 226 instruction, M2 unit 243 instruction, N2 unit 244 instruction, branch instruction, or C unit 245 instruction. Constant extension slot 1 is similar to constant extension slot 0, except that bits 0 to 4 are encoded as a unique set of bits (CSTX1) to identify constant extension slot 1. In a preferred embodiment, the constant extension slot 1 can only be used to extend the constant of one of the following instructions in the same execution package: L2 unit 241 instruction, D2 unit 226 instruction, S1 unit 222 instruction, D1 unit 225 instruction, M1 unit 223 instruction, or N1 unit 224 instruction.

[0120] The usage of constant extension slots 0 and 1 is as follows. The target instruction must be of a type that allows constant specifications. As is known in the art, this is achieved by replacing an input operand register specified field with the least significant bit of the constant, as described above regarding the scr2 / cst field 1304. The instruction decoder 113 determines this situation as the direct field from the instruction opcode bit. The target instruction also includes a constant extension bit (e bit 1307) specifically for signaling whether to not extend the specified constant (preferably, constant extension bit = 0) or to extend the constant (preferably, constant extension bit = 1). If the instruction decoder 113 detects constant extension slot 0 or constant extension slot 1, it further examines other instructions within the execution package for instructions corresponding to the detected constant extension slot. Constant extension is performed only if there is only one corresponding instruction with a constant extension bit (e bit 1307) equal to 1.

[0121] Figure 17 This is a partial block diagram 1700 showing the constant extension. Figure 17Assume that instruction decoder 113 detects a constant extension slot and a corresponding instruction in the same execution packet. Instruction decoder 113 provides 27 extended bits from the constant extension slot (bit field 1601) and 5 constant bits (bit field 1305) from the corresponding instruction to connector 1701. Connector 1701 forms a single 32-bit word from these two portions. In a preferred embodiment, the 27 extended bits from the constant extension slot (bit field 1601) are the most significant bits, and the 5 constant bits (bit field 1305) are the least significant bits. This combined 32-bit word is provided to one input of multiplexer 1702. The 5 constant bits from the corresponding instruction field 1305 provide a second input to multiplexer 1702. The selection of multiplexer 1702 is controlled by the state of the constant extension bits. If the constant extension bit (e bit 1307) is 1 (extended), multiplexer 1702 selects the connected 32-bit input. If the constant extension bits are 0 (unextended), then multiplexer 1702 selects 5 constant bits from the corresponding instruction field 1305. Multiplexer 1702 provides this output to the input of sign extension unit 1703.

[0122] The symbol extension unit 1703 forms the final operand value from the input from the multiplexer 1702. The symbol extension unit 1703 receives control inputs of scalar / vector and data size. The scalar / vector input indicates whether the corresponding instruction is a scalar instruction or a 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 the data path side A 115 can only execute scalar instructions. Any instruction pointing 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 the data path side B 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 bit. The P unit 246 can only execute scalar instructions. The data size can be 8 bits (byte B), 16 bits (half-word H), 32 bits (word W), or 64 bits (double word D).

[0123] Table 2 lists the operation of the symbol extension unit 1703 for various options.

[0124]

[0125] Table 2

[0126] Both constant extension slot 0 and constant extension slot 1 can include p bits to define the combination as described above. Figure 13The execution package. In a preferred embodiment, as in the case of condition code extension slots, constant extension slot 0 and constant extension slot 1 preferably have bits 0 (p bits) that are always encoded as 1. Therefore, neither constant extension slot 0 nor constant extension slot 1 can be located in the last instruction slot of the execution package.

[0127] It is technically feasible to include constant extension slots 0 or 1 in the execution package and more than one corresponding instruction marked as constant extension (e bit = 1). For constant extension slot 0, this would mean that more than one of the following instructions in the execution package—L1 unit 221, D1 unit 225, S2 unit 242, D2 unit 226, M2 unit 243, or N2 unit 244—has an e bit of 1. For constant extension slot 1, this would mean that more than one of the following instructions in the execution package—L2 unit 241, D2 unit 226, S1 unit 222, D1 unit 225, M1 unit 223, or N1 unit 224—has an e bit of 1. Providing the same constant extension to more than one instruction is not considered a useful feature. Therefore, in one embodiment, the instruction decoder 113 may determine that this is an invalid operation and is not supported. Alternatively, this combination can be supported by the extension bits of the constant extension slot applied to each corresponding functional unit instruction marked as constant extension.

[0128] Special vector assertion instructions use registers in assertion register file 234 to control vector operations. In the current embodiment, all these SIMD vector assertion instructions operate on a selected data size. Data sizes can include bytes (8 bits), half-words (16 bits), words (32 bits), double-words (64 bits), quad-words (128 bits), and half-vectors (256 bits). Each bit of the assertion register controls whether a SIMD operation is performed on the corresponding data byte. The operation of P unit 246 allows for various composite vector SIMD operations based on more than one vector comparison. For example, two comparisons can be used to determine a range. A candidate vector is compared to a first vector reference having the minimum value of the range packed in the first data register. A second comparison of the candidate vector is performed using a second reference vector having the maximum value of the range packed in the second data register. The logical combination of the two result assertion registers will allow vector conditional operations to determine whether each data portion of the candidate vector is within or outside the range.

[0129] Units L1 221, S1 222, L2 241, S2 242, and C 245 typically operate in 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 set in predetermined slots. SIMD operations are enabled by carry control at data boundaries. This carry control can operate on different data widths.

[0130] Figure 18 Carry control is illustrated. AND gate 1801 receives the carry output of bit N within an operand-wide arithmetic logic unit (64 bits for function unit A 115 on the scalar data path side, and 512 bits for function unit B 116 on the vector data path side). AND gate 1801 also receives a carry control signal, which will be explained further below. The output of AND gate 1801 is provided to the carry input of bit N+1 of the operand-wide arithmetic logic unit. AND gates such as AND gate 1801 are positioned between each pair of bits of possible data boundaries. For example, for 8-bit data, such AND gates would be positioned between bits 7 and 8, between bits 15 and 16, between bits 23 and 24, etc. Each such AND gate receives a corresponding carry control signal. If the data size is minimum, each carry control signal is 0, effectively preventing carry transfer between adjacent bits. If the selected data size requires two arithmetic logic unit portions, the corresponding carry control signal is 1. Table 3 below shows example carry control signals for 512-bit wide operands, which can be used by the B116 functional unit on the vector data path side, for example, in 8-bit, 16-bit, 32-bit, 64-bit, 128-bit, or 256-bit configurations. In Table 3, the high 32 bits control the carry of the high-order bits (bits 128 to 511), and the low 32 bits control the carry of the low-order bits (bits 0 to 127). There is no need to control the carry output of the most significant bit, therefore only 63 carry control signals are required.

[0131]

[0132] Table 3

[0133] For integer powers of 2 (2 N Data size manipulation is common in the art. However, this carry control technique is not limited to powers of 2. Those skilled in the art will understand how this technique can be applied to other data sizes and other operand widths.

[0134] Figure 19 A conceptual diagram of the streaming engine of the present invention is shown. Figure 19The process of a single stream is illustrated. Stream engine 1900 includes stream address generator 1901. Stream address generator 1901 generates addresses of the elements of the stream sequentially and provides these element addresses to system memory 1910. Memory 1910 retrieves data (data elements) stored at the element addresses and provides these data elements to data FIFO memory 1902. Data FIFO 1902 provides a buffer between memory 1910 and CPU 1920. Data formatter 1903 receives data elements from data FIFO memory 1902 and provides data formatting according to the stream definition. This process will be described below. Stream engine 1900 provides the formatted data elements from data formatter 1903 to CPU 1920. The program on CPU 1920 consumes this data and produces output.

[0135] Stream elements typically reside in normal memory. Memory itself does not impose a specific structure on the stream. A program imposes a structure by defining a stream by specifying the following stream properties: the address of the first element of the stream; the size and type of the elements in the stream; the formatting of the data in the stream; and the sequence of addresses associated with the stream.

[0136] The streaming engine defines the sequence of addresses of stream elements based on pointers traversed in memory. Multiple levels of nested loops control the paths taken by the pointers. The iteration count of each loop level indicates the number of times the level is repeated. The dimension indicates the distance between pointer positions within that loop level.

[0137] In a basic forward flow, the innermost loop always consumes physically contiguous elements from memory. The implicit dimension of this innermost loop is one element. The pointer itself moves from one element to another in sequentially increasing order. At each level outside the inner loop, the loop moves the pointer to a new position according to the size of the dimension of that loop level.

[0138] This addressing mode allows a program to specify a regular path through memory with a small number of parameters. Table 4 lists the addressing parameters for basic streams.

[0139]

[0140] Table 4

[0141] The above definition maps consecutive elements of a stream to increasing addresses in memory. This works for most algorithms, but not all. Some algorithms serve this better by reading elements through reverse stream addressing, reducing memory addresses. For example, discrete convolution computes the vector dot product according to the formula:

[0142]

[0143] In most DSP code, f[] and g[] represent arrays in memory. For each output, the algorithm reads f[] in the forward direction but 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 streaming engine supports reading elements in descending address order.

[0144] Matrix multiplication presents unique challenges for streaming engines. Each element in a matrix product is a vector dot product of the rows of the first matrix and the columns of 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 often stored in the same order as the language's default array order. As a result, only one of the two matrices in matrix multiplication maps to the streaming engine's 2D stream definition. In a typical example, the first index traverses the columns of the first array but the rows of the second. This problem is not unique to streaming engines. The access patterns of matrix multiplication deviate significantly from the memory hierarchies of most general-purpose applications. Some software libraries transpose one of the two matrices so that it can be accessed row-wise (or column-wise) during multiplication. Streaming engines support implicit matrix transposition using transposed streams. Transposed streams avoid the cost of explicitly transforming data in memory. The streaming engine does not access data in a strict sequential order of elements. Instead, it efficiently swaps the two internal loop dimensions in traversal order and retrieves elements back into a continuous vector channel along the second dimension.

[0145] This algorithm is effective, but impractical for small element sizes. Some algorithms work on matrix tiles, which are multi-column and multi-row. Therefore, the streaming engine defines a separate transpose granularity. The hardware imposes a minimum granularity. The transpose granularity must also be at least as large as the element size. The transpose granularity causes the streaming engine to retrieve one or more consecutive elements based on dimension 0 before moving along dimension 1. When the granularity equals the element size, this results in retrieving a single column from the row master array. Otherwise, the granularity specifies retrieving 2, 4, or more columns at a time from the row master array. This also applies to column master layouts by swapping rows and columns in the description. The parameter GRANULE indicates the transpose granularity in bytes.

[0146] Another common matrix multiplication technique swaps the innermost two loops of a matrix multiplication. The resulting inner loop no longer reads columns of one matrix but rows of the other. For example, the algorithm can hoist an item outside the inner loop and replace it with a scalar value. On a vector machine, the innermost loop can be implemented very efficiently with a single scalar-by-vector multiplication followed by vector addition. The central processing unit kernel 110 of this invention does not have scalar-by-vector multiplication. Instead, the program must copy scalar values ​​over the entire vector length and use vector-by-vector multiplication. The streaming engine of this invention directly supports this and related usage models with an element-copying mode. In this mode, the streaming engine reads particles smaller than the full vector size and copies those particles to fill the next vector output.

[0147] The streaming engine treats each complex number as a single element with two sub-elements, representing the real and imaginary parts (rectangular) or the size and angle (polar coordinates) of the complex number. Not all programs or peripherals agree on the order in which these sub-elements should appear in memory. Therefore, the streaming engine provides the ability to swap the two sub-elements of a complex number without incurring any cost. This feature swaps half of an element without interpreting its contents and can be used to swap any type of sub-element pair, not just complex numbers.

[0148] Algorithms typically prefer to work with high precision, but high-precision values ​​require more storage and bandwidth than low-precision values. Typically, programs store data in memory with low precision, promote these values ​​to higher precision for computation, and then degrade them to lower precision for storage. Streaming engines directly support this by allowing algorithms to specify the promotion of a first-level type. In a preferred embodiment of the invention, for integer types, each sub-element can be promoted to the size of the next larger type with a signed or zero extension. Streaming engines can support floating-point promotion, and it is also possible to promote 16-bit and 32-bit floating-point values ​​to 32-bit and 64-bit formats, respectively.

[0149] The streaming engine defines a stream as a discrete sequence of data elements, which the central processing unit kernel 110 consumes as continuously packed data elements in a vector. Vectors are designed to resemble streams as closely as possible, consisting of multiple elements of the same type with some implicit sequence. Because the streaming engine reads streams, but the central processing unit kernel 110 consumes vectors, the streaming engine must map streams to vectors in a consistent manner.

[0150] The vector consists of channels of equal size, each channel comprising a sub-element. The central processing unit core 110 designates the rightmost channel of the vector as channel 0, regardless of the device's current endian mode. The number of channels increases from right to left. The actual number of channels in the vector varies depending on the length of the vector and the data size of the sub-elements.

[0151] Figure 20 A first example of channel allocation in a vector is shown. Vector 2000 is divided into eight 64-bit channels (8 x 64 bits = 512 bits vector length). Channel 0 includes bits 0 to 63; channel 1 includes bits 64 to 125; channel 2 includes bits 128 to 191; channel 3 includes bits 192 to 255; channel 4 includes bits 256 to 319; channel 5 includes bits 320 to 383; channel 6 includes bits 384 to 447; and channel 7 includes bits 448 to 511.

[0152] Figure 21 A second example of channel allocation in a vector is shown. Vector 2100 is divided into 16 32-bit channels (16 x 32 bits = 512 bits vector length). Channel 0 includes bits 0 to 31; row 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; row 9 occupies bits 288 to 319; channel 10 includes bits 320 to 351; channel 11 includes bits 352 to 387; channel 12 includes bits 388 to 415; channel 13 includes bits 416 to 447; channel 14 includes bits 448 to 479; and channel 15 includes bits 480 to 511.

[0153] The streaming engine maps the innermost streaming dimension directly to vector channels. It maps earlier elements in that dimension to lower channel numbers and later elements to higher channel numbers. This is true regardless of whether the particular streaming flow is promoted in terms of address ordering (incrementing or decreasing). Regardless of the order in which the streaming flow is defined, the streaming engine stores elements in the vector in ascending channel order. For non-complex data, it places the first element retrieved by the first vector CPU kernel 110 in channel 0, the second in channel 1, and so on. For complex data, the streaming engine places the first element in channels 0 and 1, the second in channels 2 and 3, and so on. Sub-elements within an element maintain the same relative order, regardless of the streaming direction. For unswapped complex elements, this places the sub-elements with lower addresses in even-numbered channels and the sub-elements with higher addresses in odd-numbered channels. Swapped complex elements reverse this mapping.

[0154] The streaming engine populates each vector central processing unit kernel 110, retrieving as many elements as possible from the innermost streaming dimension. If the innermost dimension is not a multiple of the vector length, the streaming engine stretches that dimension to an integer multiple of the vector length using zeros. Thus, for high-dimensional streams, the first element from each iteration of the outer dimension reaches channel 0 of the vector. The streaming engine always maps the innermost dimension to consecutive channels in the vector. For transposed streams, the innermost dimension consists of groups of sub-elements along dimension 1 instead of dimension 0, because transpose swaps these two dimensions.

[0155] Compared to one-dimensional flow, two-dimensional flow exhibits significant changes. A basic two-dimensional flow retrieves a smaller rectangle from a larger one. A transposed two-dimensional flow reads the rectangle column-by-column, rather than row-by-row. The second-dimensional overlapping cyclic flow first executes a repetitive cycle of finite impulse response (FIR) filter taps or provides FIR filter samples to a sliding window of input samples.

[0156] Figure 22 A basic two-dimensional flow is illustrated. The two internal dimensions, represented by ELEM_BYTES, ICNT0, DIM1, and ICNT1, provide sufficient flexibility to describe retrieving a smaller rectangle 2220 with dimensions 2221 and 2222 from a larger rectangle 2210 with dimensions 2211 and 2212. In this example, rectangle 2220 is a 9-by-13 rectangle with 64-bit values, and rectangle 2210 is a larger 11-by-19 rectangle. The following flow parameters define this flow:

[0157] ICNT0 = 9

[0158] ELEM_BYTES = 8

[0159] ICNT1 = 13

[0160] DIM1 = 88 (11 multiplied by 8)

[0161] Therefore, the iteration count in dimension 0221 is 9. The iteration count in direction 1222 is 13. Note that ELEM_BYTES only 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 11 elements, each scaled by 8 bytes.

[0162] Figure 23This illustrates the order of elements in this example stream. The stream engine retrieves the elements of the stream in the order shown in sequence 2300. The first 9 elements come from the first row of rectangle 2220, jumping from 1 to 8 from left to right. Elements 10 through 24 come from the second row, and so on. When the stream moves from the 9th element to the 10th element ( Figure 23 (Jump 9 in the loop) The streaming engine calculates the new position based on the pointer position at the beginning of the inner loop, rather than the position of the pointer at the end of the first dimension. This makes DIM1 independent of ELEM_BYTES and ICNT0. DIM1 always represents the distance between the first bytes of each consecutive line.

[0163] Before dimension 0, the transposed flow is accessed along dimension 1. The following examples illustrate several transposed flows, varying the granularity of the transpose. Figure 24 The diagram illustrates the extraction of a smaller rectangle 2420 (12x8) with dimensions 2421 and 2422 from a larger rectangle 2410 (14x13) with dimensions 2411 and 2412. Figure 24 In this context, ELEM_BYTES equals 2.

[0164] Figure 25 This demonstrates how the streaming engine retrieves the stream of this example with a 4-byte transpose granularity; retrieval pattern 2500 retrieves element pairs from each row (because a granularity of 4 is twice that of ELEM_BYTES of 2), otherwise shifting down the column. Once the bottom of a pair of columns is reached, this pattern is repeated with the next pair of columns.

[0165] Figure 26 This demonstrates how the streaming engine retrieves the stream of this example with an 8-byte transpose granularity. The overall structure remains the same. Before moving to the next row in the column, the streaming engine retrieves 4 elements from each row (because an 8-byte granularity is four times the 2 ELEM_BYTES), as shown in retrieval pattern 2600.

[0166] So far, the stream being examined has simply read each element from memory exactly once. A stream can read a given element from memory multiple times, effectively looping through a segment of memory. FIR filters have two common looping modes. FIR rereads the same filter taps for each output. FIR also reads input samples from a sliding window. Two consecutive outputs will require inputs from two overlapping windows.

[0167] Figure 27Details of the streaming engine 2700 are shown. The streaming engine 2700 comprises three main parts: Stream 0 2710; Stream 1 2720; and a shared L2 interface 2730. Stream 0 2710 and Stream 1 2720 both include the same hardware for parallel operation. Stream 0 2710 and Stream 1 2720 both share the L2 interface 2730. Each stream 2710 and 2720 provides up to 512 bits / cycle to the central processing unit core 110. The streaming engine architecture achieves this through its dedicated streaming paths and shared dual L2 interfaces.

[0168] Each streaming engine 2700 includes a dedicated dimensional stream address generator 2711 / 2721, which can generate a new unaligned request each cycle. The address generator 2711 / 2721 outputs a 512-bit aligned address that overlaps with elements in the sequence defined by the stream parameters. This will be described further below.

[0169] Each address generator 2711 / 2711 connects to a dedicated micro-table look-aside buffer (μTLB) 2712 / 2722. Each μTLB 2712 / 2722 translates a single 48-bit virtual address to a 44-bit physical address per cycle. Each μTLB 2712 / 2722 has eight entries, ranging from a minimum of 32kB for a 4kB page to a maximum of 16MB for a 2MB page. Each address generator 2711 / 2721 produces two addresses per cycle. Each μTLB 2712 / 2722 translates only one address per cycle. To maintain throughput, the streaming engine 2700 utilizes the fact that most streaming references will reside within the same 4kB page. Therefore, address translation does not modify bits 0 through 11 of the address. If the aout0 and aout1 lines are in the same 4kB page (aout0[47:12] is the same as aout1[47:12]), then μTLB 2712 / 2722 only translates aout0 and reuses the translation of the high bits of both addresses.

[0170] The translated addresses are queued in command queues 2713 / 2723. These addresses are aligned with information from the corresponding memory allocation and trace blocks 2714 / 2724. The streaming engine 2700 does not explicitly manage μTLBs 2712 / 2722. The system memory management unit (MMU) invalidates μTLBs as needed during context switches.

[0171] Internal storage is used for storage allocation and tracking of the 2714 / 2724 management flow, enabling data reuse and tracking the lifecycle of each data segment. This will be described further below.

[0172] Reference queues 2715 / 2725 store reference sequences generated by the corresponding address generators 2711 / 2721. This information drives the data formatting network, enabling it to present data to the central processing unit core 110 in the correct order. Each entry in reference queues 2715 / 2725 includes the information required to read data from the data store and align it with the central processing unit core 110. Reference queues 2715 / 2725 maintain the following information listed in Table 5 in each slot:

[0173]

[0174] Table 5

[0175] When address generators 2711 / 2721 generate a new address, memory allocation and tracking 2714 / 2724 inserts a reference into reference queues 2715 / 2725. When data becomes available and there is space in the stream save register, memory allocation and tracking 2714 / 2724 removes the reference from reference queues 2715 / 2725. When memory allocation and tracking 2714 / 2724 removes a slot reference from reference queues 2715 / 2725 and formats the data, it checks if the reference represents the last reference for the corresponding slot. Memory allocation and tracking 2714 / 2724 compares the removal pointer of reference queues 2715 / 2725 with the last reference recorded in the slot record. If they match, memory allocation and tracking 2714 / 2724 marks the slot as inactive after data completion.

[0176] The streaming engine 2700 has data storage 2716 / 2737 for any number of elements. Deep buffering allows the streaming engine to retrieve data early in the stream, hiding memory system latency. The correct buffering amount may vary between production runs. In the currently preferred embodiment, the streaming engine 2700 uses 32 slots for each stream. Each slot holds 64 bytes of data.

[0177] The butterfly network 2717 / 2727 consists of a 7-stage butterfly network. The butterfly network 2717 / 2727 receives 128 bytes of input and produces 64 bytes of output. The first stage of the butterfly is actually half a stage. It collects matching unaligned retrieved bytes from two slots and merges them into a rotated 64-byte array. The remaining 6 stages form a standard butterfly network. The butterfly network 2717 / 2727 performs the following operations: rotates the next element down to byte channel 0; promotes the data type by a power of 2 if necessary; swaps the real and imaginary parts of complex numbers if necessary; and converts big-endian to little-endian if the central processing unit kernel 110 is currently in big-endian mode. The element size, type promotion, and real / imaginary part swapping are specified by the user as part of the stream parameters.

[0178] The Streaming Engine 2700 attempts to retrieve and format data before the Central Processing Unit (CPU) kernel 110 demands it, allowing it to maintain full throughput. Holding registers 2718 / 2728 provide a small amount of buffering to keep processes fully pipelined. Aside from the fact that the Streaming Engine 2700 provides full throughput, holding registers 2718 / 2728 are not directly visible in the architecture.

[0179] The two streams 2710 / 2720 share a pair of independent L2 interfaces 2730: L2 Interface A (IFA) 2733 and L2 Interface B (IFB) 2734. Each L2 interface provides 512 bits / cycle throughput directly to the L2 controller for a combined bandwidth of 1024 bits / cycle. The L2 interfaces use a credit-based Multicore Bus Architecture (MBA) protocol. The L2 controller allocates its own pool of command credits for each interface. The pool should have sufficient credits so that each interface can send requests sufficient to achieve full read return bandwidth when reading L2 RAM, L2 cache, and Multicore Shared Memory Controller (MSMC) memory.

[0180] To maximize performance, both streams can use two L2 interfaces, allowing a peak command rate of 2 requests / cycles per stream. Each interface preferentially selects one stream over the other, but this preference changes dynamically based on the requests. IFA 2733 and IFB 2734 always preferentially select the opposite stream; when IFA 2733 preferentializes stream 0, IFB 2734 preferentializes stream 1, and vice versa.

[0181] Arbitrators 2731 / 2732, preceding each interface 2733 / 2734, apply the following basic protocol in each cycle when they have available credit. Arbitrators 2731 / 2732 check if the preferred flow has a command ready to be sent. If so, arbitrators 2731 / 2732 select the command. Arbitrators 2731 / 2732 then check if the standby flow has at least two requests ready to be sent or one command without credit. If so, arbitrators 2731 / 2732 retrieve the command from the standby flow. If either interface issues a command, the notions of the preferred and standby flows are exchanged for the next request. Using this simple algorithm, the two interfaces dispatch requests as quickly as possible while maintaining fairness between the two flows. The first rule ensures that each flow can send a request in each cycle with available credit. The second rule provides a mechanism: when the second interface is idle, a flow can borrow from the other interface. The third rule extends the bandwidth requirements of each flow through the two interfaces, ensuring that neither interface itself becomes a bottleneck.

[0182] The coarse-grained rotators 2735 / 2736 enable the Streaming Engine 2700 to support a transposed matrix addressing mode. In this mode, the Streaming Engine 2700 swaps the two innermost dimensions of its multidimensional loop. This accesses the array column-by-column rather than row-by-row. The rotators 2735 / 2736 are architecturally invisible except when this transposed access mode is enabled.

[0183] The stream definition template provides the complete structure of the stream, including the data. Iteration counts and dimensions provide most of the structure, while various flags provide the remaining details. For all streams containing data, the stream engine defines a single stream template. All stream types it supports fit into this template. The stream engine defines six levels of nested loops for addressing elements in the stream. Most fields in the stream template directly map to parameters in the algorithm. Figure 28 The stream template register 2800 is shown. The numbers above the fields represent the number of bits within a 256-bit vector. Table 6 shows the stream field definitions for the stream template.

[0184]

[0185] Table 6

[0186] Loop 0 is the innermost loop, and loop 5 is the outermost loop. In the current example, DIM0 is always equal to ELEM_BYTES, which defines physically contiguous data. Therefore, stream template register 2800 does not define DIM0. Stream engine 2700 interprets all iteration counts as unsigned integers and all dimensions as unscaled signed integers. The template above fully specifies the type of elements, the length of the stream, and the dimensions. Stream instructions specify a start address. This is typically done by specifying a scalar register in scalar register file 211, which stores that start address. This allows a program to open multiple streams using the same template.

[0187] Figure 29 The subfield definitions of flag field 2811 are shown. For example... Figure 29 As shown, the flag field 2811 is 6 bytes or 48 bits. Figure 29 The number of digits in the field is shown. Table 7 shows the definitions of these fields.

[0188]

[0189] Table 7

[0190] The ELTYPE field 2901 defines the data type of elements in the stream. The four-bit encoding of the ELTYPE field 2901 is defined as shown in Table 8.

[0191]

[0192] Table 8

[0193] The real / complex number type determines whether the streaming engine treats each element as either a real number or two parts of a complex number (real / imaginary or magnitude / angle). This field also specifies whether to swap the two parts of a complex number. The total element size for a complex number is twice the size of its child elements. Otherwise, the child element size is equal to the total element size.

[0194] The size of the sub-element determines the type used for type promotion and vector channel width. For example, when a stream request is type promoted, a 16-bit sub-element is promoted to a 32-bit sub-element. The vector channel width is important when the CPU core 110 operates in big-endian mode because it always arranges vectors in little-endian order.

[0195] The total element size determines the smallest granularity of the stream. In the stream addressing model, it determines the number of bytes retrieved by the stream in each iteration of the innermost loop. The stream always reads the entire element, whether in ascending or descending order. Therefore, the innermost dimension of the stream spans the ICNT0x total element size in bytes.

[0196] The TRANSPOSE field 2902 determines whether the streaming engine accesses the stream in transposed order. Transposed order swaps the two addressing levels internally. The TRANSPOSE field 2902 also indicates the granularity of its transposed stream. For normal two-dimensional operations, the three-bit encoding of the TRANSPOSE field 2902 is defined as shown in Table 9.

[0197]

[0198] Table 9

[0199] The Stream Engine 2700 can transpose data elements at a granularity different from the element size. This allows programs to retrieve multiple columns of elements from each row. The transpose granularity must be no smaller than the element size. The TRANSPOSE field 2902 interacts with the DIMFMT field 2909 in the manner further described below.

[0200] The PROMOTE field 2903 controls whether the stream engine promotes child elements in the stream and the type of promotion. When enabled, the stream engine 2700 promotes types by powers of 2. The three-bit encoding of the PROMOTE field 2903 is defined as shown in Table 10.

[0201]

[0202] Table 10

[0203] When PROMOTE is 000, it corresponds to 1x promotion; each child element remains unchanged and occupies a vector channel of the same width as specified by ELTYPE. When PROMOTE is 001, it corresponds to 2x promotion and zero extension; each child element is treated as an unsigned integer and zero-extended to twice the width of the vector channel specified by ELTYPE. For an initial child element size of 64 bits, 2x promotion has no effect. When PROMOTE is 010, it corresponds to 4x promotion and zero extension; each child element is treated as an unsigned integer and zero-extended to four times the width of the vector channel specified by ELTYPE. For an initial child element size of 32 bits or 64 bits, 4x promotion has no effect. When PROMOTE is 011, it corresponds to 8x promotion and zero extension; each child element is treated as an unsigned integer and zero-extended to eight times the width of the vector channel specified by ELTYPE. For an initial child element size of 16 bits, 32 bits, or 64 bits, 8x promotion has no effect. When PROMOTE is 101, it corresponds to 2x promotion and sign extension. Each child element is treated as a signed integer, and the sign is extended to twice the width of the vector channel specified by ELTYPE. For an initial child element size of 64 bits, 2x promotion has no effect. When PROMOTE is 110, it corresponds to 4x promotion and sign extension. Each child element is treated as a signed integer, and the sign is extended to four times the width of the vector channel specified by ELTYPE. For an initial child element size of 32 bits or 64 bits, 4x promotion has no effect. When PROMOTE is 111, it corresponds to 8x promotion and zero extension. Each child element is treated as a signed integer, and the sign is extended to eight times the width of the vector channel specified by ELTYPE. For an initial child element size of 16 bits, 32 bits, or 64 bits, 8x promotion has no effect.

[0204] The VECLEN field 2904 defines the stream vector length of the stream in bytes. The stream engine 2700 breaks the stream down into groups of elements of length VECLEN bytes. The three-bit encoding of the VECLEN field 2904 is defined as shown in Table 11.

[0205]

[0206] Table 11

[0207] VECLEN must be greater than or equal to the product of the element size in bytes and the repetition factor. The streaming engine 2700 presents this stream to the central processing unit kernel 110 as a sequence of single vector pairs or a sequence of two vectors. When VECLEN is shorter than the native vector width of the central processing unit kernel 110, the streaming engine 2700 fills in additional channels in the vector provided to the central processing unit kernel 110. The GRDUP field 2906 determines the type of filling. The VECLEN field 2904 interacts with the ELDUP field 2905 and the GRDUP field 2906 in the manner detailed below.

[0208] The ELDUP field 2905 specifies the number of times each element is repeated. The size of the element multiplied by the number of repetitions must not exceed 64 bytes. The three-bit encoding of the ELDUP field 2905 is defined as shown in Table 12.

[0209]

[0210] Table 12

[0211] The ELDUP field 2905 interacts with the VECLEN field 2904 and the GRDUP field 2906 in the manner detailed below.

[0212] GRDUP bit 2906 determines whether group replication is enabled. If GRDUP bit 2906 is 0, group replication is disabled. If GRDUP bit 2906 is 1, group replication is enabled. When enabled by GRDUP bit 2906, the streaming engine 2700 replicates a set of elements to fill the vector width. VECLEN field 2904 defines the length of the group to be replicated. When VECLEN field 2904 is less than the vector length of the central processing unit core 110 and GRDUP bit 2906 enables group replication, the streaming engine 2700 fills additional channels with additional copies of the streaming vector (see [link to relevant documentation]). Figure 20 and Figure 21 Because the stream vector length and the vector length of the CPU core 110 are always powers of 2, group replication always produces a power of 2 in the number of replicates. The GRDUP field 2906 specifies how the stream engine 2700 pads the stream vector outwards to the vector length of the CPU core 110. When the GRDUP bit 2906 is 0, the stream engine 2700 pads the extra channels with zeros and marks these extra vector channels as invalid. When the GRDUP bit 2906 is 1, the stream engine 2700 pads the extra channels with a copy of the element group in each stream vector. Setting the GRDUP bit 2906 to 1 has no effect when VECLEN is set to the original vector width of the CPU core 110.

[0213] The DECIM field 2907 controls the extraction of data elements from the corresponding stream. When stored in the first registers 2718 / 2728, the stream engine 2700 removes data elements from the stream to present them to the requesting functional unit. Extraction always removes the entire data element, not its sub-elements. The definition of the DECIM field 2907 is listed in Table 13.

[0214]

[0215] Table 13

[0216] If DECIM field 2907 equals 00, no decimation occurs. The data element is transferred to the corresponding head register 2718 / 2728. If DECIM field 2907 equals 01, a 2:1 decimation occurs. While stored in head register 2718 / 2728, the streaming engine 2700 removes odd-numbered elements from the data stream. Constraints in the formatted network require 2:1 decimation, data promotion of at least 2x (PROMOTE cannot be 000), ICNT0 must be a multiple of 2, and the total vector length (VECLEN) must be large enough to accommodate a single promoted, copied element. For transposed streams (TRANSPOSE ≠ 0), the transposed element must be at least twice the size of the element in bytes before promotion. If DECIM field 2907 equals 10, a 4:1 decimation occurs. While stored in head register 2718 / 2728, the streaming engine 2700 retains three elements removed from the data stream for each fourth data element. The formatted network requires a 4:1 slur, boosting the data by at least 4x (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 accommodate a single boosted, duplicated element. For transposed streams (TRANSPOSE ≠ 0), slurring always removes columns, never rows. Therefore, the transpose granularity must be: at least twice the element size in bytes before boosting for 2:1 slur (GRANULE ≥ 2 x ELEM_BYTES); and at least four times the element size in bytes before boosting for 4:1 slur (GRANULE ≥ 4 x ELEM_BYTES).

[0217] The THROTTLE field 2908 controls the level of activity the flow engine retrieves before the central processing unit core 110. The two bits of this field are encoded as shown in Table 14.

[0218]

[0219] Table 14

[0220] `THROTTLE` does not change the meaning of the stream and serves only as a hint. The streaming engine may ignore this field. Programs should not rely on specific throttling behavior to guarantee program correctness, as the architecture does not specify precise throttling behavior. `THROTTLE` allows programmers to provide hints to the hardware about the program's own behavior. By default, the streaming engine attempts to lead the CPU core 110 as far as possible to hide as much latency as possible while providing full streaming throughput to the CPU core 110. While several critical applications require this level of throughput, it can lead to other undesirable system-level behaviors. For example, the streaming engine discards all data retrieved via context switching. Therefore, in systems with a large number of context switches, aggressive early retrieval can result in wasted bandwidth. Aggressive early retrieval is only meaningful in systems where the CPU core 110 consumes data very quickly.

[0221] DIMFMT field 2909 enables the redefinition of the cycle count fields ICNT0 2801, ICNT1 2802, ICNT2 2803, ICNT3 2804, ICNT4 2805, and ICNT5 2806, the cycle dimension fields DIM1 2855, DIM2 2823, DIM3 2824, DIM4 2825, and DIM5 2826, and the addressing mode fields AM0 2913, AM1 2914, AM2 2915, AM3 2916, AM4 2917, and AM5 2918 (part of FLAGS field 2811) of stream template register 2800. This allows some cycle dimension fields and cycle counts to include more bits, at the cost of fewer cycles. Table 15 lists the size of the cycle dimension fields for various values ​​of DIMFMT field 2909.

[0222]

[0223] Table 15

[0224] Note that DIM0 is always equal to the size of the ELEM_BYTES data element. Table 16 lists the size of the cycle count field for various values ​​of the DIMFMT field 2909.

[0225]

[0226] Table 16

[0227] The DIMFMT field 2909 effectively defines the loop dimension and loop count bits of the stream template register 2800. Figure 28 This shows the default case when DIMFMT is 111.

[0228] Figures 30 to 34 The definitions of the bits for the stream template register for the other values ​​of DIMFMT are shown. Note that the positions and meanings of the FLAGS fields (2811, 3011, 3111, 3211, 3311, and 3411) are the same for all values ​​of DIMFMT.

[0229] Figure 30 The bit definitions of stream template register 3000 are shown for a DIMFMT value of 000. For a DIMFMT value of 000, there are three loops: loop0, loop2, and loop4. For loop0, ICNT0 field 3001 includes bits 0 through 31, and the DIM0 field is equal to ELEM_BYTES. For loop2, ICNT2 field 3002 includes bits 32 through 63, and DIM2 field 3021 includes bits 160 through 191. For loop4, INTC4 field 3003 includes bits 64 through 95, and DIM4 field 3022 includes bits 192 through 223.

[0230] Figure 31 The bit definitions of stream template register 3100 for a DIMFMT value of 001 are shown. For a DIMFMT value of 001, there are four loops: loop0, loop1, loop2, and loop4. For loop0, ICNT0 field 3101 includes bits 0 through 16, and the DIM0 field is equal to ELEM_BYTES. For loop1, ICNT1 field 3002 includes bits 16 through 31, and DIM1 field 3123 includes bits 224 through 255. For loop2, INTC2 field 3103 includes bits 32 through 63, and DIM2 field 3121 includes bits 160 through 191. For loop4, INTC4 field 3104 includes bits 64 through 95, and DIM4 field 3122 includes bits 192 through 223.

[0231] Figure 32 The bit definitions of stream template register 3200 for a DIMFMT value of 010 are shown. For a DIMFMT value of 010, there are four loops: loop0, loop2, loop3, and loop4. For loop0, ICNT0 field 3201 includes bits 0 through 32, and the DIM0 field is equal to ELEM_BYTES. For loop2, ICNT2 field 3202 includes bits 32 through 47, and the DIM2 field 3221 includes bits 160 through 191. For loop3, INTC3 field 3203 includes bits 48 through 63, and the DIM3 field 3223 includes bits 224 through 255. For loop4, INTC4 field 3204 includes bits 64 through 95, and the DIM4 field 3222 includes bits 192 through 223.

[0232] Figure 33 The bit definitions of stream template register 3300 for a DIMFMT value of 011 are shown. For a DIMFMT value of 011, there are five loops: loop0, loop1, loop2, loop3, and loop4. For loop0, ICNT0 field 3401 includes bits 0 through 15, and the DIM0 field is equal to ELEM_BYTES. For loop1, ICNT1 field 3402 includes bits 16 through 31, and DIM1 field 3421 includes bits 144 through 159. For loop2, ICNT2 field 3403 includes bits 32 through 47, and DIM2 field 3221 includes bits 160 through 191. For loop3, INTC3 field 3204 includes bits 48 through 63, and DIM3 field 3424 includes bits 224 through 255. For loop4, INTC4 field 3405 includes bits 64 through 95, and DIM4 field 3423 includes bits 192 through 223.

[0233] Figure 34 The bit definitions of stream template register 3400 are shown for a DIMFMT value of 101. For a DIMFMT value of 110, there are six loops: loop0, loop1, loop2, loop3, loop4, and loop5. For loop0, ICNT0 field 3501 includes bits 0 through 15, and the DIM0 field is equal to ELEM_BYTES. For loop1, ICNT1 field 3502 includes bits 16 through 31, and DIM1 field 3421 includes bits 144 through 159. For loop2, ICNT2 field 3503 includes bits 32 through 47, and DIM2 field 3422 includes bits 160 through 191. For loop3, INTC3 field 3504 includes bits 48 through 63, and DIM3 field 3425 includes bits 224 through 255. For loop4, INTC4 field 3405 includes bits 64 through 79, and DIM4 field 3423 includes bits 192 through 207. For loop 5, INTC5 field 3506 includes bits 80 to 95, and DIM5 field 3424 includes bits 208 to 223.

[0234] DIR bit 2910 determines the retrieval direction of the inner loop (Loop0). If DIR bit 2910 is 0, Loop0 retrieval is in the positive direction towards increasing address. If DIR bit 2910 is 1, Loop0 retrieval is in the negative direction towards decreasing address. The retrieval direction of the other loops is determined by the sign of the corresponding loop dimensions DIM1, DIM2, DIM3, DIM4, and DIM5, which are signed integers.

[0235] CBK0 field 2911 and CBK1 field 2912 control the circular block size when circular addressing is selected. The method for determining the circular block size will be described in more detail below.

[0236] Fields AM0 (2913), AM1 (2914), AM2 (2915), AM3 (2916), AM4 (2917), and AM5 (2918) control the addressing mode of the corresponding loop. This allows the addressing mode to be specified independently for each loop. Each of fields AM0 (2913), AM1 (2914), AM2 (2915), AM3 (2916), AM4 (2917), and AM5 (2918) is three bits and is decoded as listed in Table 17.

[0237]

[0238] Table 17

[0239] In linear addressing, the address advances or backs up according to address arithmetic. In circular addressing, the address remains within a defined address block. Upon reaching the end of the circular address block, the address wraps around other constraints of the block. Circular addressing blocks are typically limited to 2 bytes. N Let N be an integer, and N be the address. Circular address arithmetic can be performed by cutting the carry chain between bits and disallowing changes to the selected number of most significant bits. Therefore, arithmetic beyond the end of the circular block only changes the least significant bit.

[0240] The block size settings are listed in Table 18.

[0241]

[0242] Table 18

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

[0244] Figure 35 An exemplary embodiment of a loop count selection circuit 3500, which selects data from a stream template register for various loop dimensions, is shown. Figure 28 and Figures 30 to 34As shown, the stream template register bits that define the loop counter vary according to the DIMFMT field. Figure 35 Bits 0 through 95 of the stream template register are shown. These bits are divided into 6 parts, including: part 3501, bits 0 through 15; part 3502, bits 16 through 31; part 3503, bits 32 through 47; part 3504, bits 48 through 63; part 3505, bits 64 through 79; and part 3506, bits 80 through 95.

[0245] Connector 3511 forms a single 32-bit data word from sections 3501 and 3502. Multiplexer 3512 selects the output of section 3501 or connector 3511 for INCT0 output. Multiplexer 3513 selects either a blank input or section 3502 for INCT1 output.

[0246] Connector 3521 forms a single 32-bit data word from sections 3503 and 3504. Multiplexer 3522 selects either the output of section 3503 or connector 3521 for the INCT2 output. Multiplexer 3523 selects either a blank input or section 3504 for the INCT3 output.

[0247] Connector 3531 forms a single 32-bit data word from sections 3505 and 3506. Multiplexer 3532 selects the output of section 3505 or connector 3531 for INCT4 output. Multiplexer 3533 selects either a blank input or section 3506 for INCT5 output.

[0248] The DIMFMT ICNT decoder 3508 receives the DIMFT bits from the stream template register and generates outputs that control the selection of multiplexers 3512, 3513, 3522, 3523, 3532, and 3533. Table 19 lists the control of these multiplexers for various encodings of the DIMFMT field.

[0249]

[0250] Table 19

[0251] Figure 36 The loop dimension selection circuit 3600 is shown, which is an exemplary embodiment of selecting data for various loop dimensions from a stream template register. Note that DIM0 (the loop dimension of loop0) is always ELEN_BYTES. Figure 28 and Figures 30 to 34 As shown, the stream template register bits that define the loop dimension vary according to the DIMFMT field. Figure 36Bits 144 to 255 of the stream template register are shown. These bits are divided into six parts, including: part 3601, bits 144 to 159; part 3602, bits 160 to 175; part 3603, bits 176 to 191; part 3604, bits 192 to 207; part 3605, bits 208 to 223; and part 3606, bits 224 to 255.

[0252] Connector 3611 forms a single 32-bit data word from portions 3602 and 3603. Multiplexer 3612 selects the output of DIM1 from portion 3601, a blank input, or portion 3606. Multiplexer 3613 selects the output of DIM2 from portion 3602 or the output of connector 3611. Multiplexer 3614 selects the output of DIM3 from portion 3604, a blank input, or portion 3606.

[0253] Connector 3621 forms a single 32-bit data word from sections 3604 and 3605. Multiplexer 3622 selects either section 3604 or the output of connector 3621 for the DIM4 output. Multiplexer 3623 selects either a blank input, section 3605, or section 3606 for the DIM5 output.

[0254] The DIMFMT DIM decoder 3607 receives the DIMFT bits from the stream template register and generates outputs that control the selection of multiplexers 3612, 3613, 33614, 3622, and 353. Table 20 lists the control of these multiplexers for various encodings of the DIMFMT field.

[0255]

[0256] Table 20

[0257] Figure 37An example of an adder control word circuit 3700 is shown, which generates the adder control word for the loop address generator described below. The addressing mode fields AM0 2913, AM1 2914, AM2 2915, AM3 2916, AM4 2917, and AM5 2918 each control the addressing mode of the corresponding loop for the stream engine address. The address control word circuit 3700 is provided to each supported loop for the stream engine address. Adder 3701 forms a sum of CBK0, CBK1, and 1. Fields CBK0 and CBK1 are each a 4-bit field and are part of the EFLAGS field of the corresponding stream template register. Fields CBK0 and CBK1 are provided to the operand input of adder 3701. The quantity + 1 is provided to the carry input of the least significant bit of adder 3701. This structure implements three-term addition without special adder hardware. The sum output of adder 3710 provides one input to multiplexer 3702. The second input of multiplexer 3702 is empty. The third input of multiplexer 3702 is CBK0. Multiplexer 3702 is controlled by the AMx field of the corresponding loop. If AMx is 000, multiplexer 3702 selects an empty input. If AMx is 001, multiplexer 3702 selects the CBK0 input. If AMx is 010, multiplexer 3702 selects the sum CBK0 + CBK1 + 1 output by adder 3701. The output of multiplexer 3702 is used as an index in adder control word lookup table 3703. The adder control word accessed from adder control word lookup table 3703 is used to combine in a manner similar to the above. Figure 18 The SIMD control method described in Table 3 controls the corresponding cyclic adder (see Table 3). Figure 38 The corresponding cyclic adders include, for example: Figure 18 The carry interrupt circuit is shown, followed by the bits corresponding to the supported block sizes listed in Table 18. The adder control word lookup table 3703 includes control words for various block sizes, such as those listed in Table 3. The selected number CBK0 or CBK0+CBK1+1 indexes the appropriate adder control word. If the multiplexer 3702 selects an empty input corresponding to linear addressing, the corresponding adder control word is all 1s, allowing the adder to carry across all address bits.

[0258] Figure 38A partial schematic diagram of the address generator 3800 of the stream engine 2700 is shown. The address generator 3800 forms the address for retrieving the next element in the defined stream of the corresponding stream engine. The start address register 3801 stores the start address of the data stream. As previously mentioned, the start address register 3801 is preferably a scalar register in the global scalar register file 211, specified by the STROPEN instruction, which opens the corresponding stream. As is known in the art, this start address can be copied from the specified scalar register and stored locally at the corresponding address generator 2711 or 2721. The first loop of the stream employs a Loop0 counter register 3811, an adder 3812, a multiplier 3813, and a comparator 3814. The Loop0 counter register 3811 stores a working copy of the iteration count of the first loop (Loop0). For each iteration of the Loop0 adder 3812, triggered by the Next Address signal, the loop count is incremented by 1, and this loop count is stored back in the Loop0 counter register 3811. Multiplier 3813 multiplies the current loop count by the quantity ELEM_BYTES. ELEM_BYTES is the size (in bytes) of each data element in the loop. Loop0 iterates through physically contiguous data elements in memory, with a step size of ELEM_BYTES.

[0259] Comparator 3814 compares the count stored in Loop0 count register 3811 (after being incremented by adder 3812) with the value of ICNT0 2801 from the corresponding stream template register 2800. As described above, depending on the state of DIMFMT field 2909, the Loop0 count can be in section 3001, section 3101, section 3201, section 3301, or section 3401. The iteration of Loop0 is complete when the output of adder 3812 equals the value of ICNT0 2801 in stream template register 2800. Comparator 3814 generates a valid Loop0 end signal. Loop0 count register 3811 is reset to 0, and the next iteration of a higher loop, in this case Loop1, is triggered.

[0260] The circuit for higher loops (Loop1, Loop2, Loop3, Loop4, Loop5) is similar to Figure 38The circuit shown is as follows. Each loop includes a corresponding working loop counter register, an adder, a multiplier, and a comparator. The adder in 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 of the corresponding stream template. The comparator in each loop compares the working loop register count with the corresponding iteration values ​​ICNT1, ICTN2, ICTN3, ICTN4, and ICTN5 of the corresponding stream template registers. The loop end signal generates the iteration for the next higher loop. The loop end signal from loop 5 terminates the stream.

[0261] Figure 38 Adder 3812, which receives an adder control word, is shown. As described above, the adder control word is all 1s for linear addressing and has 0s at appropriate positions for cyclic addressing. The positions of 0s in the adder control word correspond to the cyclic block size in cyclic addressing mode.

[0262] The central processing unit kernel 110 exposes the stream engine to programs through a small number of instructions and special-purpose registers. The STROPEN instruction opens a stream. The STROPEN command specifies the stream number that indicates stream 0 or stream 1 is open. STROPEN specifies the stream template register that stores the stream template as described above. Table 21 lists a summary of the STROPEN instruction.

[0263]

[0264] Table 21

[0265] The stream start address register is preferably a scalar register in general-purpose scalar register file 211. The STROPEN instruction specifies stream 0 or stream 1 via its opcode. The stream template register is preferably a vector register in general-purpose vector register file 221. If the specified stream is active, the STROPEN instruction closes the previous stream and replaces it with the specified stream.

[0266] The STRCLOSE command closes a stream. The STRCLOSE command specifies the stream number of the stream to be closed.

[0267] The STRSAVE instruction captures enough status information for the specified stream to restart it in the future. The STRRSTR instruction restores a previously saved stream. The STRSAVE instruction does not save any data of the stream. The STRSAVE instruction only saves metadata. The stream responds to the STRRSTR instruction to retrieve its data.

[0268] The streaming engine is in one of three states: inactive; active; or frozen. When inactive, the streaming engine does nothing. Any attempt to retrieve data from an invalid streaming engine will result in an error. The streaming engine is inactive until a program opens the stream. The streaming engine also becomes inactive after a program consumes all elements in the stream or closes the stream. Programs using streams can explicitly activate and deactivate the streaming engine. Combined with its own explicit save and restore operations, the operating environment manages the stream across context switching boundaries through the implicit freezing behavior of the streaming engine.

[0269] An active stream engine has a stream associated with it. A program can retrieve new stream elements from an active stream engine. A stream engine remains active until one of the following occurs: It becomes inactive when the stream retrieves its last element; it becomes inactive when the program explicitly closes the stream; or it freezes when the central processing unit kernel 110 responds to an interrupt or exception. When a stream engine freezes, it captures all the state required to restore the stream. The stream engine freezes in response to interrupts and exceptions. This is combined with special instructions to save and restore the frozen stream context so that the operating environment can clearly switch contexts. When the central processing unit kernel 110 returns to the interrupted context, the frozen stream is reactivated.

[0270] Figure 39 This is a partial schematic diagram 3900 showing the encoding of the above-mentioned stream input operands. Figure 39 The src1 field 1305 of the decoding function unit 3920 corresponding to the src1 input of an instruction is shown. The same circuitry is replicated for the src2 / cst field 1304 and the src2 input of the function unit 3920. Furthermore, this circuitry is replicated for each instruction within an execution packet that can be dispatched simultaneously.

[0271] The instruction decoder 113 receives bits 13 to 17 of the src1 field 1305, which includes the instruction. The opcode field (bits 4 to 12 of all instructions and bits 28 to 31 of any additional unconditional instructions) explicitly specifies the corresponding functional unit 3920. In this embodiment, the functional unit 3920 may be L2 unit 241, S2 unit 242, M2 unit 243, N2 unit 244, or C unit 245. Figure 39The relevant part of the instruction decoder 113 shown decodes the src1 bit field 1305. Sub-decoder 3911 determines whether the src1 bit field 1305 is in the range from 00000 to 01111. If so, sub-decoder 3911 provides the corresponding register number to the global vector register file 231. In this example, this register field is the four least significant bits of the src1 bit field 1305. The global vector register file 231 retrieves the data stored in the register corresponding to that register number and provides that data to the src1 input of functional unit 3920. This decoding is generally known in the art.

[0272] Sub-decoder 3912 determines whether the src1 bit field 1305 is within the range of 10000 to 10111. If so, sub-decoder 3912 provides the corresponding register number to the corresponding local vector register file. If the instruction points to L2 unit 241 or S2 unit 242, the corresponding local vector register file is local vector register field 232. If the instruction points to M2 unit 243, N2 unit 244, or C unit 245, the corresponding local vector register file is local vector register field 233. In this example, this register field is the three least significant bits of the src1 bit field 1305. The corresponding local vector register file 232 / 233 retrieves the data stored in the register corresponding to that register number and provides that data to the src1 input of function unit 3920. This decoding is generally known in the art.

[0273] Sub-decoder 3913 determines whether src1 bit field 1305 is 11100. If so, sub-decoder 3913 provides the stream 0 read signal to stream engine 2700. Stream engine 2700 then provides the stream 0 data stored in holding register 2718 to the src1 input of function unit 3920.

[0274] Sub-decoder 3914 determines whether the src1 bit field 1305 is 11101. If so, sub-decoder 3914 provides a stream 0 read signal to stream engine 2700. Stream engine 2700 then provides the stream 0 data stored in holding register 2718 to the src1 input of function unit 3920. Sub-decoder 3914 also provides an advance signal to stream 0. As previously described, stream engine 2700 advances to store the next sequential data element of stream 0 in holding register 2718.

[0275] Sub-decoder 3915 determines whether the src1 bit field 1305 is 11110. If so, sub-decoder 3915 provides the stream 1 read signal to stream engine 2700. Stream engine 2700 then provides the stream 1 data stored in holding register 2728 to the src1 input of function unit 3920.

[0276] Sub-decoder 3916 determines whether the src1 bit field 1305 is 11111. If so, sub-decoder 3916 provides a stream 1 read signal to stream engine 2700. Stream engine 2700 then provides the stream 1 data stored in holding register 2728 to the src1 input of function unit 3920. Sub-decoder 3914 also provides an advance signal to stream 1. As previously described, stream engine 2700 advances to store the next sequential data element of stream 1 in holding register 2728.

[0277] In response to the bit encoding of the src2 / cst field 1304, a similar circuit is used to select the data provided to the scr2 input of functional unit 3902. A constant input can be provided to the src2 input of functional unit 3920 in the manner described above.

[0278] Determining the exact number of instruction bits specified in the operands, as well as the number of data registers and data streams, is a design choice. Those skilled in the art will recognize that other number choices described in this application are feasible. In particular, specifying a single global vector register file and omitting a local vector register file are feasible. This invention employs bit encoding of the input operand selection field to specify stream reads and another bit encoding to specify stream reads and forward streams.

Claims

1. A method comprising: A series of data elements are read from memory using multiple nested loops, wherein for each nested loop, the read includes: Receive parameters including the first cyclic addressing block size parameter and the second cyclic addressing block size parameter; Determine a corresponding addressing mode selected as one of a linear addressing mode, a first circular addressing mode with a first circular block size, or a second circular addressing mode with a second circular block size, wherein the first circular block size is determined based on the first circular addressing block size parameter rather than the second circular addressing block size parameter, and the second circular block size is determined based on both the first circular addressing block size parameter and the second circular addressing block size parameter; and Use the corresponding addressing mode to read the data elements associated with the nested loop; and The series of data elements are output to the processing kernel.

2. The method of claim 1, wherein determining the corresponding addressing mode for each nested loop comprises reading a plurality of fields from a stream definition template associated with the series of data elements, wherein each of the plurality of fields specifies the addressing mode for a corresponding one of the nested loops.

3. The method according to claim 2, wherein the stream definition template is stored in a register.

4. The method of claim 2, wherein the flow definition template includes a first circular block size field containing the first circular addressing block size parameter (CBK0) and a second circular block size field containing the second circular addressing block size parameter (CBK1).

5. The method of claim 4, wherein the second circular block size is determined based on the sum of CBK0 and CBK1.

6. The method of claim 4, wherein the second circular block size is determined to be equal to: CBK0 + CBK1 + 1.

7. The method according to claim 1, wherein: The first cyclic block size is selected from block sizes ranging from 512 bytes (B) to 512 kilobytes (KB); and Select the second cyclic block size from a block size range of 1 megabyte (MB) to 64 gigabytes (GB).

8. The method according to claim 1, wherein: The first circular block size is selected from the following block sizes: 512 bytes, 1 kilobyte (KB), 2 KB, 4 KB, 8 KB, 16 KB, 32 KB, 64 KB, 128 KB, 256 KB, 512 KB, 1 megabyte (MB), 2 MB, 4 MB, 8 MB, and 16 MB; and The second cyclic block size is selected from the following block sizes: 1KB, 2KB, 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1M, 2MB, 4MB, 8MB and 16MB, 32MB, 64MB, 128MB, 256MB, 512MB, 1 gigabyte (GB), 2GB, 4GB, 8GB, 16GB, 32GB and 64GB.

9. A data processing apparatus, comprising: Process the kernel; Memory; A register, configured to store a stream definition template including multiple addressing mode fields; as well as A streaming engine unit, coupled to the processing kernel and the memory, is configured to receive multiple data elements from the memory using multiple nested loops and provide the multiple data elements as a data stream to the processing kernel, wherein, for each nested loop, receiving the multiple data elements from the memory includes: Receive parameters including the first cyclic addressing block size parameter and the second cyclic addressing block size parameter; A corresponding addressing mode is determined, selected as one of a linear addressing mode, a first circular addressing mode with a first circular block size, or a second circular addressing mode with a second circular block size, wherein the first circular block size is determined based on the first circular addressing block size parameter rather than the second circular addressing block size parameter, and the second circular block size is determined based on both the first and second circular addressing block size parameters; and The determined addressing mode is used to cause the data element associated with the nested loop to be read from the memory.

10. The data processing apparatus according to claim 9, wherein, Each of the addressing mode fields of the stream definition template corresponds to a corresponding one in the nested loop, and wherein the determination of the corresponding addressing mode for each nested loop is based on the value in the corresponding addressing mode field of the stream definition template.

11. The data processing apparatus according to claim 10, wherein, The flow definition template includes a first circular block size field containing the first circular addressing block size parameter (CBK0) and a second circular block size field containing the second circular addressing block size parameter (CBK1).

12. The data processing apparatus according to claim 11, wherein, The size of the second circular block is determined based on the sum of CBK0 and CBK1.

13. The data processing apparatus according to claim 11, wherein, The size of the second circular block is determined to be equal to: CBK0 + CBK1 + 1.

14. The data processing apparatus according to claim 9, wherein: The first cyclic block size is selected from block sizes ranging from 512 bytes (B) to 512 kilobytes (KB); and Select the second cyclic block size from a block size range of 1 megabyte (MB) to 64 gigabytes (GB).

15. The data processing apparatus according to claim 9, wherein: The first circular block size is selected from the following block sizes: 512 bytes, 1 kilobyte (KB), 2 KB, 4 KB, 8 KB, 16 KB, 32 KB, 64 KB, 128 KB, 256 KB, 512 KB, 1 megabyte (MB), 2 MB, 4 MB, 8 MB, and 16 MB; and The second cyclic block size is selected from the following block sizes: 1KB, 2KB, 4KB, 8KB, 16KB, 32KB, 64KB, 128KB, 256KB, 512KB, 1M, 2MB, 4MB, 8MB and 16MB, 32MB, 64MB, 128MB, 256MB, 512MB, 1 gigabyte (GB), 2GB, 4GB, 8GB, 16GB, 32GB and 64GB.

16. An apparatus comprising: A stream template register, configured to store a stream template, the stream template including a set of address mode indicators, the set of address mode indicators including a corresponding address mode indicator for each loop of a set of nested loops; An address generator, coupled to the stream template register to receive the set of addressing mode indicators, wherein the address generator includes: For each loop in the set of nested loops, a control word circuit associated with the corresponding loop in the set of nested loops is configured to provide a corresponding control word specifying the memory block size of the corresponding loop in response to the corresponding addressing mode indicator of the loop, wherein the memory block size is selected as one of null, a first block size, or a second block size, wherein: The size of the first block is determined based on the first circular addressing parameter, not the second circular addressing parameter; and The size of the second block is determined based on both the first and second circular addressing parameters; and An adder circuit, coupled to the control word circuit to receive the corresponding control word, and configured to cyclically traverse memory regions according to the corresponding control word when the memory block size is selected as either the first block size or the second block size, such that the address generator provides a set of addresses representing the set of nested cycles using the selected memory block size; and A memory interface, coupled to the address generator to receive the address set, and configured to retrieve a dataset associated with the address set from the memory.

17. The apparatus according to claim 16, wherein: The flow template also includes the first block size and the second block size; and Each of the set of addressing mode indicators is selected between the first block size and a function of both the first block size and the second block size.

18. The apparatus according to claim 17, wherein, For each of the nested loops in the set, the corresponding control word circuitry includes: An adder, coupled to provide a sum by adding the first block size to the second block size; A multiplexer, coupled to select between the first block size and the sum to provide a table index; and A lookup table unit, coupled to the multiplexer and configured to provide the corresponding control word in response to the table index.

19. The apparatus according to claim 18, wherein, For each of the nested loops, the adder is configured to add the first block size, the second block size, and 1 to produce the sum.

20. The apparatus according to claim 17, wherein, Each of the set of addressing mode indicators is further selected between circular addressing based on the first block size, circular addressing based on a function of the first block size and the second block size, and linear addressing.

21. The apparatus of claim 16, wherein for each cycle of the set of nested loops: The adder circuit is configured to perform a carry operation set; and The corresponding control word specifies whether to execute each of the carry operations in the set.

22. The apparatus of claim 16, further comprising a stream start register coupled to the memory interface for storing the dataset.

23. The apparatus of claim 22, further comprising a processor coupled to the stream head register to receive the dataset.

24. The apparatus of claim 23, wherein the stream start register is configured to provide the dataset as a data stream to the processor.

25. The apparatus according to claim 23, wherein: The processor is configured to provide a read signal to the stream head register; and The stream head register is configured to provide the processor with data elements of the dataset in response to the read signal.

26. The apparatus according to claim 23, wherein: The processor is configured to provide an advance signal to the stream start register; and The stream start register is configured to respond to the advance signal: The processor is provided with the first data element of the dataset; and Load the second data element of the dataset.

27. A method comprising: Receives a template specifying a set of addressing mode indicators for a set of nested loops; and The dataset associated with the set of nested loops is retrieved using the following steps: For each of the nested loops in the set: In response to the corresponding addressing mode indicator associated with the corresponding loop in the set of nested loops, a corresponding control word is provided specifying the memory block size of the corresponding loop, wherein the memory block size is selected as null, a first block size, or a second block size, wherein: The size of the first block is determined based on the first circular addressing parameter, not the second circular addressing parameter; and The size of the second block is determined based on both the first and second circular addressing parameters; and When the memory block size is selected as either the first block size or the second block size, the memory regions are traversed cyclically according to the corresponding control word to provide an address set representing the set of nested cycles using the selected memory block size; and The dataset is retrieved from memory based on the address set.

28. The method of claim 27, wherein: The template also specifies the size of the first block and the size of the second block; and Each of the set of addressing mode indicators is selected between the first block size and a function of both the first block size and the second block size.

29. The method of claim 28, further comprising, for each of the set of nested loops: Based on the corresponding addressing mode indicator, a choice is made between the first block size and the sum of the first block size and the second block size to provide a table index; and The corresponding control word is provided in response to the table index.

30. The method of claim 29, further comprising, for each iteration of the set of nested loops, adding the first block size, the second block size, and 1 to generate the sum.

31. The method according to claim 28, wherein, Each of the set of addressing mode indicators is further selected between circular addressing based on the first block size, circular addressing based on a function of the first block size and the second block size, and linear addressing.

32. The method according to claim 27, wherein, For each of the nested loops in the set: The cyclic traversal of the memory region includes performing a set of carry operations; and The corresponding control word specifies whether to execute each of the carry operations in the set.

33. The method of claim 27 further includes storing the dataset in a stream head register.

34. The method of claim 33, further comprising providing the dataset from the stream head register as a data stream to the processor.

35. The method of claim 34, further comprising: Receive a read signal from the processor; and In response to the read signal, the data elements of the dataset are provided to the processor.

Images