Variable delay instruction

By employing a variable delay instruction execution method, the problem of low memory access and instruction scheduling efficiency of digital signal processors in multiprocessor environments is solved, achieving more efficient data processing, reducing pipeline hazards, and improving real-time data processing capabilities.

CN113853584BActive Publication Date: 2025-12-19TEXAS INSTRUMENTS INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202080037631.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-04-15
Filing Date
2020-04-15
Publication Date
2025-12-19
Estimated Expiration
2040-04-15

AI Technical Summary

Technical Problem

Existing digital signal processors suffer from low memory access and instruction scheduling efficiency when processing real-time data, especially when multiple processors share memory, leading to uncertainties in data processing latency and potential pipeline hazards.

Method used

A variable delay instruction execution method is adopted. By receiving and storing the expected amount of time required for instruction execution, adjusting the delay value, starting instruction execution on the instruction execution pipeline, and updating the ready state when outputting results, the instructions are ensured to be completed in sequence.

Benefits of technology

It improves the memory access efficiency and data scheduling accuracy of digital signal processors in multiprocessor environments, reduces pipeline hazards, and enhances the processor's real-time data processing capabilities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113853584B_ABST
    Figure CN113853584B_ABST
Patent Text Reader

Abstract

The technology relates to executing instructions by a processor, including receiving a first instruction for execution, determining a first stall value based on an expected amount of time required to execute the first instruction, storing the first stall value in a write back queue (1306), starting execution of the first instruction on an instruction execution pipeline, adjusting the stall value based on an amount of time that has elapsed since starting execution of the first instruction, outputting a first result of the first instruction based on the stall value, receiving a second instruction, determining that the second instruction is a variable stall instruction, storing in the write back queue (1306) a ready value indicating that a second result of the second instruction is not ready, starting execution of the second instruction on the instruction execution pipeline, updating the ready value to indicate that the second result is ready, and outputting the second result.
Need to check novelty before this filing date? Find Prior Art

Description

BACKGROUND

[0001] Digital signal processors (DSPs) are optimized for processing data streams that can be derived from a variety of input signals, such as sensor data, video streams, voice channels, radar signals, biomedical signals, etc. A digital signal processor operating on real-time data can receive an input data stream, perform a filtering function (such as encoding or decoding) on the data stream, and output a transformed data stream. A system is said to be real-time if the transformed data stream is not available for output if scheduled. Video encoding can exploit input data patterns that are predictable but not sequential. Many applications require memory accesses to load data registers in a data register file and then supply data from the data registers to a functional unit that performs data processing.

[0002] One or more DSP processing cores can be combined with various peripheral circuits, memory blocks, etc. on a single integrated circuit (IC) die to form a system on a chip (SoC). The advent of SoC architectures for embedded systems has created a number of challenges for software development systems used to develop and debug software applications executing on these architectures. These systems can include multiple interconnected processors that share the use of on-chip and off-chip memory. The processors can include some combination of instruction caches (ICaches) and data caches (DCaches) to improve processing. In addition, multiple processors with memory shared among them can be incorporated into a single embedded system. The processors can physically share the same memory without accessing data located in the same memory location or executing code located in the same memory location, or they can use some portion of the shared memory as a common shared memory.

[0003] In early microprocessors, instruction execution was "atomic" in the sense that the processor fetched an instruction and executed it completely before fetching and executing another instruction. Modern microprocessors typically execute instructions in several steps, rather than atomically. This series of steps is called the "instruction execution pipeline," or just the "pipeline." The pipeline can include several stages, including steps to read an instruction from memory, decode the instruction, read the values to operate on, execute the operation, and write the result to some type of storage. This is called a "pipeline" because the processor can execute several instructions simultaneously at different stages, i.e., "in the pipeline." In this mode of operation, the processor can fetch an instruction while it is decoding a previous instruction, while it is reading the input values for an even earlier instruction, etc. By overlapping the execution of instructions, we increase the rate at which the processor can execute instructions.

[0004] One implication of pipelining is that an instruction in the "read input" stage can require a value produced by an earlier instruction, but the "write" of the value has not yet occurred. There are generally two ways to handle this situation: the processor looks for these situations and inserts appropriate stalls in the pipeline, or the programmer arranges the instructions so that the situation does not occur by scheduling dependent instructions far enough apart. The former solution is generally referred to as a "protected" pipeline, and the latter solution is referred to as an "unprotected" pipeline. Many modern general-purpose architectures implement a "protected" pipeline.

[0005] Protected pipelines have the advantage that they allow CPU designers to deepen the pipeline in subsequent generations of processors while still executing legacy code correctly. However, protected pipelines can require a significant amount of logic to detect situations where a stall should be inserted in the pipeline.

[0006] Unprotected pipelines have the advantage that when executing instructions that require more than one CPU cycle to execute in the pipeline, they require little / no hardware control mechanisms to produce the correct program result. The programmer or compiler is responsible for scheduling the instructions so that an instruction is complete before a subsequent instruction requires its result. Unprotected pipelines allow the use of "multiple assignment" code, where multiple writes to a particular register can be done simultaneously in the pipeline. This is a very low cost, low complexity alternative to register renaming, or in processors without register renaming, having enough registers in the architecture to hold all running computations, and is useful for high performance low power Digital Signal Processing (DSP) applications.

[0007] Existing processors are generally designed to have either protected or unprotected behavior. SUMMARY

[0008] The description generally relates to the field of DSPs. More specifically, but not by way of limitation, aspects of the description relate to methods for executing multiple instructions by a processor. One such method includes executing, by a processor, a plurality of instructions by receiving a first instruction for execution on an instruction execution pipeline. The method also includes determining a first stall value based on an expected amount of time required to execute the first instruction. The method further includes storing the first stall value in a writeback queue that stores information associated with instruction execution. The method also includes starting execution of the first instruction on the instruction execution pipeline. The method further includes adjusting the stall value based on an amount of time elapsed since starting execution of the first instruction. The method also includes outputting a first result of the first instruction based on the stall value. The method further includes receiving a second instruction for execution on the instruction execution pipeline. The method also includes determining that the second instruction is a variable stall instruction. The method further includes storing in the writeback queue a ready value indicating that a second result of the second instruction is not ready. The method also includes starting execution of the second instruction on the instruction execution pipeline. The method further includes updating the ready value to indicate that the second result is ready based on a determination that execution of the second instruction has completed. The method also includes outputting the second result.

[0009] Another aspect of the description relates to a processor that includes an instruction execution pipeline having a plurality of pipeline stages. The processor also includes pipeline circuitry configured to receive a first instruction for execution on the instruction execution pipeline. The pipeline circuitry is further configured to determine a first stall value based on an expected amount of time required to execute the first instruction. The pipeline circuitry is also configured to store the first stall value in a writeback queue that stores information associated with instruction execution. The pipeline circuitry is further configured to start execution of the first instruction on the instruction execution pipeline. The pipeline circuitry is also configured to adjust the stall value based on an amount of time elapsed since starting execution of the first instruction. The pipeline circuitry is further configured to output a first result of the first instruction based on the stall value. The pipeline circuitry is also configured to receive a second instruction for execution on the instruction execution pipeline. The pipeline circuitry is further configured to determine that the second instruction is a variable stall instruction. The pipeline circuitry is also configured to store in the writeback queue a ready value indicating that a second result of the second instruction is not ready. The pipeline circuitry is further configured to start execution of the second instruction on the instruction execution pipeline. The pipeline circuitry is also configured to update the ready value to indicate that the second result is ready based on a determination that execution of the second instruction has completed. The pipeline circuitry is further configured to output the second result.

[0010] Another aspect of the description relates to a processing system comprising a memory and a processor. The processor also comprises an instruction execution pipeline having a plurality of pipeline stages. The processor further comprises pipeline circuitry configured to receive a first instruction for execution on the instruction execution pipeline. The pipeline circuitry is also configured to determine a first stall value based on an expected amount of time required to execute the first instruction. The pipeline circuitry is further configured to store the first stall value in a writeback queue that stores information associated with instruction execution. The pipeline circuitry is also configured to start execution of the first instruction on the instruction execution pipeline. The pipeline circuitry is further configured to adjust the stall value based on an amount of time elapsed since starting execution of the first instruction. The pipeline circuitry is also configured to output a first result of the first instruction based on the stall value. The pipeline circuitry is further configured to receive a second instruction for execution on the instruction execution pipeline. The pipeline circuitry is also configured to determine that the second instruction is a variable stall instruction. The pipeline circuitry is further configured to store in the writeback queue a ready value indicating that a second result of the second instruction is not ready. The pipeline circuitry is also configured to start execution of the second instruction on the instruction execution pipeline. The pipeline circuitry is further configured to update the ready value to indicate that the second result is ready based on a determination that execution of the second instruction has completed. The pipeline circuitry is also configured to output the second result. BRIEF DESCRIPTION OF DRAWINGS

[0011] For a detailed description of various examples, reference will now be made to the accompanying drawings in which:

[0012] Figure 1 An example processor having multiple data paths is described.

[0013] Figure 2 Details of functional units and register files of an example processor are described.

[0014] Figure 3 A global scalar register file of an example processor is described.

[0015] Figures 4 to 6 A local register file of an example processor is described.

[0016] Figure 7 Pipeline stages of an example processor are described.

[0017] Figure 8 A circuit diagram illustrating an example functional unit within a data path and a capture queue according to some aspects.

[0018] Figure 9An example functional unit, capture queue, and scoreboard complex according to some aspects is illustrated.

[0019] Figure 10 An example capture queue register bit field according to some aspects is illustrated.

[0020] Figure 11 A timing diagram of an example capture queue according to some aspects is illustrated.

[0021] Figure 12 An example writeback queue according to some aspects is illustrated.

[0022] Figure 13 An example circuit for variable latency lifetime tracking according to some aspects is illustrated.

[0023] Figure 14 A flowchart illustrating a technique for executing multiple instructions by a processor according to some aspects is illustrated. DETAILED DESCRIPTION

[0024] Digital signal processors (DSPs) are optimized for processing data streams that can be derived from a variety of input signals, such as sensor data, video streams, voice channels, radar signals, biomedical signals, etc. Memory bandwidth and scheduling are concerns for digital signal processors operating on real-time data. An example DSP processing core including a stream engine to improve processing efficiency and data scheduling will be described below.

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

[0026] Depending on the particular technology and cost / performance tradeoffs, various embodiments of processing cores within a given family can have different numbers of instruction pipeline stages. The embodiments described herein are representative and include multiple pipeline stages.

[0027] Figure 1 An example processor 100 including dual scalar / vector data paths 115, 116 is illustrated. The processor 100 includes separate level one instruction cache (LI I) 121 and level one data cache (LID) 123. The processor 100 includes an L2 combined instruction / data cache (L2) 130 that holds both instructions and data. Figure 1 A connection between the LI I cache and the L2 combined instruction / data cache 130 over a 512-bit bus 142 is illustrated. Figure 1The connection between the L1 D cache 123 and the L2 combined instruction / data cache 130 is over a 512-bit bus 145. In this example of the processor 100, the L2 combined instruction / data cache 130 stores both instructions backing the L1 I cache 121 and data backing the L1 D cache 123. In this example, the L2 combined instruction / data cache 130 uses Figure 1 Known or later developed memory system technology not explained in the foregoing is further connected to higher level caches and / or main memory. In various examples, the L1 I cache 121, the L1 D cache 123, and the L2 cache 130 can be implemented in different sizes; in this example, the L1 I cache 121 and the L1 D cache 123 are each 32 kilobytes, and the L2 cache 130 is 1024 kilobytes. In this example, the central processing unit core 110, the L1 I cache 121, the L1 D cache 123, and the L2 combined instruction / data cache 130 are formed on a single integrated circuit. This single integrated circuit optionally includes other circuitry.

[0028] The central processing unit core 110 fetches instructions from the L1 I cache 121 as controlled by the instruction fetch unit 111. The instruction fetch unit 111 determines the next instruction to execute and invokes the fetch packet size set for such instruction. The nature and size of the fetch packet is further detailed below. Instructions are fetched directly from the L1 I cache 121 on a cache hit (if the instructions are stored in the L1 I cache 121). On a cache miss (the specified instruction fetch packet is not stored in the L1 I cache 121), the instructions are sought in the L2 combined cache 130. In this example, the size of a cache line in the L1 I cache 121 is equal to the size of a fetch packet, i.e., 512 bits. The memory location of the instructions is a hit or miss in the L2 combined cache 130. Hits are serviced from the L2 combined cache 130. Misses are serviced from a higher level cache (not illustrated) or from main memory (not illustrated). In this example, the requested instructions are supplied to both the L1 I cache 121 and the central processing unit core 110 concurrently for speed of use.

[0029] In this example, the central processing unit core 110 includes multiple functional units to perform data processing tasks specified by instructions. An instruction dispatch unit 112 determines the target functional unit for each fetched instruction. In this example, the central processing unit 110 operates as a very long instruction word (VLIW) processor capable of operating on multiple instructions in corresponding functional units simultaneously. Typically, a compiler organizes the instructions in execution packets that are executed together. The instruction dispatch unit 112 directs each instruction to its target functional unit. The functional unit assigned to an instruction is specified entirely by the instruction produced by the compiler. The hardware of the central processing unit core 110 does not participate in this functional unit assignment. In this example, the instruction dispatch unit 112 can operate on multiple instructions in parallel. The number of such parallel instructions is set by the size of the execution packet. This is described further below.

[0030] An instruction decode unit 113 decodes each instruction in the current execution packet. Decoding includes identifying the functional unit to execute the instruction, identifying the registers from among the possible register files to supply data for the corresponding data processing operation, and identifying the register target for the result of the corresponding data processing operation. As described below, an instruction can include one constant field in place of one register number operand field. The result of this decoding is signals to control the target functional unit to perform the data processing operation specified by the corresponding instruction on the specified data.

[0031] The central processing unit core 110 includes control registers 114. The control registers 114 store information for control of the functional units in scalar data path side A 115 and vector data path side B 116. This information can include mode information or the like.

[0032] The decoded instructions from the instruction decode 113 and the information stored in the control registers 114 are supplied to the scalar data path side A 115 and the vector data path side B 116. As a result, the functional units within the scalar data path side A 115 and the vector data path side B 116 perform the data processing operations specified by the instructions on the data specified by the instructions and store the results in the data registers specified by the instructions. Each of the scalar data path side A 115 and the vector data path side B 116 includes multiple functional units operating in parallel. These are described in further detail below. Figure 2 Further detail on these is provided below. There is a data path 117 between the scalar data path side A 115 and the vector data path side B 116 that allows data exchange.

[0033] The central processing unit core 110 contains further non-instruction based modules. The emulation unit 118 allows determination of the machine state of the central processing unit core 110 in response to instructions. This capability can be used for algorithm development. The interrupt / exception unit 119 enables the central processing unit core 110 to respond to external asynchronous events (interrupts) and to attempts to perform improper operations (exceptions).

[0034] The processor 100 contains a stream engine 125. The stream engine 125 supplies two data streams from predetermined addresses, typically cached in the L2 combined cache 130, to the register file of the vector data path side B of the central processing unit core 110. This provides controlled data movement from memory (such as cached in the L2 combined cache 130) directly to functional unit operand inputs.

[0035] Figure 1 An example data width of the bus between various components is illustrated. The LI I cache 121 supplies instructions to the instruction fetch unit 111 via bus 141. In this example, the bus 141 is a 512-bit bus. The bus 141 is unidirectional from the LI I cache 121 to the central processing unit 110. The L2 combined cache 130 supplies instructions to the LI I cache 121 via bus 142. In this example, the bus 142 is a 512-bit bus. The bus 142 is unidirectional from the L2 combined cache 130 to the LI I cache 121.

[0036] The LI D cache 123 exchanges data with the register file in the scalar data path side A 115 via bus 143. In this example, the bus 143 is a 64-bit bus. The LI D cache 123 exchanges data with the register file in the vector data path side B 116 via bus 144. In this example, the bus 144 is a 512-bit bus. The buses 143 and 144 are illustrated as bidirectional to support both central processing unit 110 data reads and data writes. The LI D cache 123 exchanges data with the L2 combined cache 130 via bus 145. In this example, the bus 145 is a 512-bit bus. The bus 145 is illustrated as bidirectional to support cache servicing for both central processing unit 110 data reads and data writes.

[0037] Processor data requests are fetched directly from the L1 D cache 123 on a cache hit (if the requested data is stored in the L1 D cache 123). On a cache miss (the specified data is not stored in the L1 D cache 123), the data is looked up in the L2 combined cache 130. The memory location of this requested data is a hit or miss in the L2 combined cache 130. Hits are serviced from the L2 combined cache 130. Misses are serviced from another level of cache (not illustrated) or from main memory (not illustrated). The requested data can be supplied to both the L1 D cache 123 and the central processing unit core 110 simultaneously to speed usage.

[0038] The L2 combined cache 130 supplies data of a first data stream to the stream engine 125 via a bus 146. In this example, the bus 146 is a 512-bit bus. The stream engine 125 supplies data of this first data stream to the functional units of the vector data path side B 116 via a bus 147. In this example, the bus 147 is a 512-bit bus. The L2 combined cache 130 supplies data of a second data stream to the stream engine 125 via a bus 148. In this example, the bus 148 is a 512-bit bus. The stream engine 125 supplies data of this second data stream to the functional units of the vector data path side B 116 via a bus 149, which is a 512-bit bus in this example. According to this example, the buses 146, 147, 148, and 149 are illustrated as unidirectional from the L2 combined cache 130 to the stream engine 125 and to the vector data path side B 116.

[0039] Figure 2 Further details of the functional units and register files within the scalar data path side A 115 and the vector data path side B 116 are illustrated. The scalar data path side A 115 includes an L1 unit 221, an S1 unit 222, an M1 unit 223, an N1 unit 224, a D1 unit 225, and a D2 unit 226. The 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. The vector data path side B 116 includes an L2 unit 241, an S2 unit 242, an M2 unit 243, an N2 unit 244, a C unit 245, and a P unit 246. The 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 a predicate register file 234. There are restrictions on what functional units can read from what register file or write to what register file. These are described below.

[0040] Scalar datapath side A 115 includes Ll unit 221. Ll unit 221 typically takes two 64-bit operands and produces a 64-bit result. Each of the two operands is fetched from an instruction specified register in global scalar register file 211 or Ll / Sl local register file 212. Ll unit 221 can perform the following instruction selected operations: 64-bit add / subtract operations; 32-bit min / max operations; 8-bit single instruction multiple data (SIMD) instructions such as sum of absolute values, min and max determination, circular min / max operations, and various move operations between register files. The result can be written to an instruction specified register in global scalar register file 211, Ll / Sl local register file 212, Ml / Nl local register file 213, or Dl / D2 local register file 214.

[0041] Scalar datapath side A 115 includes S 1 unit 222. S 1 unit 222 typically takes two 64-bit operands and produces a 64-bit result. Each of the two operands is fetched from an instruction specified register in global scalar register file 211 or Ll / Sl local register file 212. In this example, S 1 unit 222 performs the same type of operations as Ll unit 221. In another example, there can be minor variations between the data processing operations supported by Ll unit 221 and S 1 unit 222. The result can be written to an instruction specified register in global scalar register file 211, Ll / Sl local register file 212, Ml / Nl local register file 213, or Dl / D2 local register file 214.

[0042] Scalar datapath side A 115 includes Ml unit 223. Ml unit 223 typically takes two 64-bit operands and produces a 64-bit result. Each of the two operands is fetched from an instruction specified register in global scalar register file 211 or Ml / Nl local register file 213. In this example, Ml unit 223 performs the following instruction selected operations: 8-bit multiply operations; complex dot product operations; 32-bit count operations; complex conjugate multiply operations; and bitwise logical operations, moves, adds, and subtracts. The result can be written to an instruction specified register in global scalar register file 211, Ll / Sl local register file 212, Ml / Nl local register file 213, or Dl / D2 local register file 214.

[0043] Scalar datapath side A 115 includes Nl units 224. Nl units 224 generally take two 64-bit operands and produce a 64-bit result. Each of the two operands is fetched from an instruction specified register in global scalar register file 211 or Ml / Nl local register file 213. In this example, Nl units 224 perform the same type of operations as Ml units 223. There can be certain dual operations that employ both Ml units 223 and Nl units 224 together (referred to as dual issue instructions). The result can be written into an instruction specified register of global scalar register file 211, Ll / Sl local register file 212, Ml / Nl local register file 213, or Dl / D2 local register file 214.

[0044] Scalar datapath side A 115 includes Dl units 225 and D2 units 226. Dl units 225 and D2 units 226 generally each take two 64-bit operands and each produce a 64-bit result. Dl units 225 and D2 units 226 generally perform address calculations and corresponding load and store operations. Dl units 225 are used for scalar loads and stores of 64 bits. D2 units 226 are used for vector loads and stores of 512 bits. In this example, Dl units 225 and D2 units 226 also perform: swapping, packing, and unpacking of load and store data; 64-bit SIMD arithmetic operations; and 64-bit bitwise logical operations. Dl / D2 local register file 214 is generally used to store base and offset addresses used in corresponding load and store address calculations. Each of the two operands is fetched from an instruction specified register in global scalar register file 211 or Dl / D2 local register file 214. The result of the calculation can be written into an instruction specified register of global scalar register file 211, Ll / Sl local register file 212, Ml / Nl local register file 213, or Dl / D2 local register file 214.

[0045] Vector datapath side B 116 includes L2 units 241. L2 units 241 generally take two 512-bit operands and produce a 512-bit result. Each of the two operands is fetched from an instruction specified register in global vector register file 231, L2 / S2 local register file 232, or predicate register file 234. In this example, L2 units 241 perform similar instructions as Ll units 221, but not on the wider 512-bit data. The result can be written into an instruction specified register of global vector register file 231, L2 / S2 local register file 232, M2 / N2 / C local register file 233, or predicate register file 234.

[0046] Vector datapath side B 116 includes S2 units 242. S2 units 242 generally take two 512-bit operands and produce a 512-bit result. Each of the two operands is fetched from an instruction specified register in global vector register file 231, L2 / S2 local register file 232, or predicate register file 234. In this example, S2 units 242 execute similar instructions as S1 units 222. The result can be written to an instruction specified register in global vector register file 231, L2 / S2 local register file 232, M2 / N2 / C local register file 233, or predicate register file 234.

[0047] Vector datapath side B 116 includes M2 units 243. M2 units 243 generally take two 512-bit operands and produce a 512-bit result. Each of the two operands is fetched from an instruction specified register in global vector register file 231 or M2 / N2 / C local register file 233. In this example, M2 units 243 execute similar instructions as M1 units 223, except on wider 512-bit data. The result can be written to an instruction specified register in global vector register file 231, L2 / S2 local register file 232, or M2 / N2 / C local register file 233.

[0048] Vector datapath side B 116 includes N2 units 244. N2 units 244 generally take two 512-bit operands and produce a 512-bit result. Each of the two operands is fetched from an instruction specified register in global vector register file 231 or M2 / N2 / C local register file 233. In this example, N2 units 244 perform the same type of operations as M2 units 243. There can be certain dual operations (called dual issue instructions) that employ both M2 units 243 and N2 units 244 together. The result can be written to an instruction specified register in global vector register file 231, L2 / S2 local register file 232, or M2 / N2 / C local register file 233.

[0049] Vector datapath side B 116 includes correlation (C) units 245. C units 245 generally take two 512-bit operands and produce a 512-bit result. Each of the two operands is fetched from an instruction specified register in global vector register file 231 or M2 / N2 / C local register file 233.

[0050] Vector datapath side B 116 includes P units 246. Vector predicate (P) units 246 perform basic logical operations on registers of local predicate register file 234. P units 246 have direct access to read from and write to predicate register file 234.

[0051] Figure 3 The global scalar register file 211 is illustrated. There are 16 independent 64-bit wide scalar registers designated A0 through A15. Each register of the global scalar register file 211 can be read or written as 64-bit scalar data. All scalar data path side A 115 functional units (LI unit 221, SI unit 222, Ml unit 223, Nl unit 224, Dl unit 225, and D2 unit 226) can read or write the global scalar register file 211. The global scalar register file 211 can be read as 32-bit or 64-bit, and can only be written as 64-bit. The execution instruction determines the read data size. 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 read from the global scalar register file 211 via the cross path 117 with the limitations detailed below.

[0052] Figure 4 The Dl / D2 local register file 214 is illustrated. There are 16 independent 64-bit wide scalar registers designated D0 through D16. Each register of the Dl / D2 local register file 214 can be read or written as 64-bit scalar data. All scalar data path side A 115 functional units (LI unit 221, SI unit 222, Ml unit 223, Nl unit 224, Dl unit 225, and D2 unit 226) can write to the global scalar register file 211. Only Dl unit 225 and D2 unit 226 can read from the Dl / D2 local scalar register file 214. It is expected that the data stored in the Dl / D2 local scalar register file 214 will include base addresses and offset addresses used in address calculations.

[0053] Figure 5 The LI / S 1 local register file 212 is illustrated. In this example, the LI / S 1 local register file 212 includes eight independent 64-bit wide scalar registers designated AL0 through AL7. In this example, the instruction encoding allows the LI / S 1 local register file 212 to include up to 16 registers. In this example, only eight registers are implemented to reduce circuit size and complexity. Each register of the LI / S 1 local register file 212 can be read or written as 64-bit scalar data. All scalar data path side A 115 functional units (LI unit 221, SI unit 222, Ml unit 223, Nl unit 224, Dl unit 225, and D2 unit 226) can write to the LI / S 1 local scalar register file 212. Only LI unit 221 and SI unit 222 can read from the LI / S 1 local scalar register file 212.

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

[0055] Figure 7 The following pipeline stages are illustrated: program fetch stage 710, dispatch and decode stage 720, and execution stage 730. The program fetch stage 710 contains three stages for all instructions. The dispatch and decode stage 720 contains three stages for all instructions. The execution stage 730 contains one to four stages depending on the instruction.

[0056] The fetch stage 710 contains a program address generation (PG) stage 711, a program access (PA) stage 712, and a program receive (PR) stage 713. During the program address generation stage 711, a program address is generated in the processor and a read request is sent to the memory controller for the L1 I cache. During the program access stage 712, the L1 I cache processes the request, accesses data in its memory and sends a fetch packet to the processor boundary. During the program receive stage 713, the processor registers the fetch packet.

[0057] The processor core 110( Figure 1 ) and the L1 I cache 121 pipeline Figure 1 are decoupled from each other. The return of the fetch packet from the L1 I cache can take a different number of clock cycles depending on the external environment, such as whether there is a hit in the L1 I cache 121 or a hit in the L2 combined cache 130. Therefore, the program access stage 1112 can take several clock cycles instead of one clock cycle as in the other stages.

[0058] The instructions executed in parallel constitute an execution packet. In this example, an execution packet can contain up to 16 32-bit wide slots for 16 instructions. No two instructions in an execution packet can use the same functional unit. A slot is one of five types: 1) a self-contained instruction executed 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 processor core 110; 2) a no-unit instruction, such as a NOP (no operation) instruction or multiple NOP instructions; 3) a branch instruction; 4) a constant field extension; and 5) a condition code extension. Some of these slot types will be described below.

[0059] The dispatch and decode stage 720 Figure 7 includes instruction dispatch to the appropriate execution unit (DS) stage 721, instruction predecode (DC1) stage 722, and instruction decode, operand read (DC2) stage 723. During instruction dispatch to the appropriate execution unit stage 721, the fetch packet is split into execution packets and assigned to the appropriate functional units. During the instruction predecode stage 722, the source registers, destination registers, and associated paths are decoded for executing the instruction in the functional unit. During the instruction decode, operand read stage 723, more detailed unit decoding is completed, and operands are read from the register file.

[0060] The execution stage 730 includes execution (E1-E5) stages 731-735. Different types of instructions require different numbers of these stages to complete their execution. These stages of the pipeline play an important role in understanding the state of the apparatus at a processor loop boundary.

[0061] During the E1 stage 731, the condition of the instruction is evaluated and the operands are operated on. As explained in Figure 7 E1 stage 731 can receive operands from the stream buffer 741 and one of the register files, shown schematically as 742. For load and store instructions, the address is generated and the address modification is written to the register file. For branch instructions, the branch fetch packet in the PG stage is affected. As explained in Figure 7 Load and store instructions access memory, shown schematically here as memory 751. For single-cycle instructions, 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 pipeline operations after the E1 stage 731.

[0062] During E2 stage 732, load instructions send addresses to memory. Store instructions send addresses and data to memory. If saturation occurs, a single-cycle instruction that saturates the result sets a saturation (SAT) bit in the control status register (CSR). For 2-cycle instructions, the result is written to the destination register file.

[0063] During E3 stage 733, data memory accesses are performed. If saturation occurs, any multiply instruction that saturates the result sets a SAT bit in the control status register (CSR). For 3-cycle instructions, the result is written to the destination register file.

[0064] During E4 stage 734, load instructions bring data to the processor boundary. For 4-cycle instructions, the result is written to the destination register file.

[0065] During E5 stage 735, load instructions write data into registers. This is illustrated schematically in Figure 7 Fig. 11B with input from memory 751 to E5 stage 1135.

[0066] As described above, processor 100 can operate in both protected mode and unprotected mode. In some cases, pipeline protection can be enabled or disabled by setting a processor bit. For example, protection can be controlled by setting a bit in a control register, such as a task status register. In some cases, instructions can be used to set the protection mode, such as PROT or UNPROT.

[0067] Unprotected mode or exposed pipeline mode is a common VLIW mode of operation. Unprotected mode can require the programmer or compiler to understand the latency of instructions and insert NOPS or other instructions between dependent instructions to ensure correctness. For example, a first instruction MPY32 A0, Al, A2; multiply can be received by the processor. This instruction takes four processor cycles to execute and output to the A2 register. If the programmer or compiler wishes to use the output of the MPY32 instruction for a second instruction, such as ADD A2, A8, A8; accumulate, then three NOP instructions are inserted by the programmer or compiler to obtain correct behavior. However, unexpected events, such as a processing interrupt or cache miss, can cause the NOP instructions inserted by the programmer or compiler to be inaccurate.

[0068] In protected or non-exposed pipeline mode, the pipeline conforms to the sequential operation model, where dependent instructions are guaranteed to be correct, regardless of how many cycles it takes to complete an instruction. For instructions that take multiple cycles to complete, if a subsequent instruction attempts to read the destination of the first instruction within the first instruction's delay slot, the CPU pipeline will automatically insert NOP cycles until the instruction that writes to the register has completed. In the example above, if the processor 100 receives an MPY32 instruction followed by an ADD instruction in protected mode, the processor 100 will automatically insert three NOP cycles between the instructions.

[0069] Pipeline hazards can exist in certain processors, such as multi-stage pipeline processors that are capable of processing multiple instructions in the pipeline. Unresolved pipeline hazards are generally situations in which the processor can produce an unexpected or unintended result. Different types of pipeline hazards can exist. Two such types include data hazards and structural hazards. Data hazards generally occur when an instruction executing in the pipeline involves data from a previous instruction. If not handled, data hazards can result in race conditions. Generally, data hazards include write-after-read and write-after-write. Examples of data hazards include, but are not limited to, when an instruction attempts to access the result of a previous instruction that is still being processed at a later time.

[0070] Structural hazards generally occur due to the structure of the data path of the processor. Certain processors can be limited in the way that writes are performed. In one such example, a single functional unit can be capable of performing a single write to an output register file per clock cycle, where two instructions attempt to output their results to the same register within a single cycle. Thus, when a first instruction that takes two clock cycles to complete is executed on a functional unit followed by a second instruction that takes one clock cycle to complete on the same functional unit, both instructions will complete within the same cycle and attempt to write to the output register file.

[0071] In certain processors, when executing in protected mode, when a pipeline dependency is found, all functional units from instruction fetch to the E1 stage and the entire execution pipeline can stall. Since all functional units stall, no units are allowed to advance until the pipeline conflict has been resolved. To help resolve data hazard situations, fast processor mode switching is enabled, and load / store stalls are resolved in both protected and unprotected modes, and recoverable interrupts are enabled in unprotected mode, a trap queue can be used. The trap queue structure helps save the state of the pipeline registers, and then writes the saved state back, such as to continue execution or out to the general register file. The trap queue can be used to detect hazard conditions, generate appropriate stalls, and load and unload trap queue registers to help resolve pipeline hazards in protected mode. Although interrupts and exceptions are different concepts, they can be handled by the processor in a similar manner, and the terms can be used interchangeably in this description, as described herein.

[0072] In certain situations, a trap queue can also be used in conjunction with a processor executing in unprotected mode or a processor having an unprotected pipeline. For example, a trap queue can be used to help enable recoverable interrupts. As an example, a processor can receive a four-cycle MPY32 instruction that outputs to the A2 register in four cycles. When the processor is in unprotected mode, the execution code can then issue a one-cycle shift right (SHR) instruction on the data currently in A2. The SHR instruction can then be followed by a one-cycle move (MV) instruction that moves the shifted data in A2 to the A3 register. A NOP can then be inserted, and then the result of the MPY instruction is output to A2. An ADD instruction can then be executed using the data from A2. If an interrupt is received after the SHR instruction but before the MV, an undesirable result can occur. For example, the transfer to the interrupt handler can ensure that all pending writes in the pipeline are completed before the execution of the interrupt handler begins to avoid the results from the interrupt handler corrupting the program. Thus, the interrupt handler will allow the MPY32 instruction to complete and output to A2. After the interrupt handler returns, the result of the MPY32 will be restored to A2, and the next instruction, MV, will execute. However, the MV instruction will now execute on the result of the MPY32, instead of the result of the SHR instruction.

[0073] Figure 8is a circuit diagram 800 illustrating example functionality units and capture queues within a data path according to aspects of the present description. While shown in the context of a scalar data path, in some cases, capture queues can be utilized with both scalar and vector data paths. According to certain aspects, a capture queue can include a scoreboard 802 (which includes hazard detection logic), local unit capture queues 804A-804E (collectively 804), and a central capture queue 806. The scoreboard 802 includes a writeback queue comprising a set of registers, and the scoreboard 802 is coupled to a set of associated functionality units 808A-808E (collectively 808) and the central capture queue 806. The functionality units 808 can each be associated with a respective local unit capture queue 804.

[0074] According to certain aspects, capture queues help enable recoverable interrupts in pipelined processors. As described above, a processor pipeline can include multiple stages, each stage performing discrete steps to process instructions. Multiple instructions can be executing at different stages of the pipeline. For example, it is relatively inefficient to stall and flush the entire pipeline to handle an interrupt. Moreover, interrupt handler instructions are executed via the processor pipeline stages, and flushing the entire pipeline will not change the number of cycles required to clear the interrupt handler instructions from the processor pipeline. Instead of discarding partially executed instructions, execution of these instructions can continue to completion, and the results stored to a capture queue structure. For example, a four-cycle MPY32 instruction can be received, followed by a multi-cycle load (LDD) instruction in the next processor cycle. When the LDD instruction is received, the MPY32 instruction is in E2 cycle. During processing in El, the LDD instruction causes a cache miss, resulting in an exception. The LDD instruction is then discarded and an exception handler is loaded. However, the MPY32 instruction can continue to execute to completion in E2-E4 stages, and the results of the MPY32 instruction are stored in the capture queue. In some cases, the results of the MPY32 instruction can be stored in the central capture queue 806, as the instructions of the exception handler can require local capture queues 804. As the MPY32 instruction continues, the instructions of the exception handler can also be executing in the pipeline. Once the exception handler completes, the LDD instruction can be reissued to El for execution, and the results of the MPY32 instruction are restored to the local capture queue 804 for output to an output register.

[0075] According to some aspects, progress of instructions that take more than one execution cycle to execute can be tracked to help ensure that information is written to the correct location and at the correct time. For example, scoreboard 802 can include a writeback queue. In some cases, the writeback queue can be a set of registers that can be used to store information associated with executing instructions. A writeback queue slot associated with an executed instruction can be associated with a particular slot in local capture queue 804 and include a pointer to the particular slot. Information in the writeback queue can include a lifetime tracking value that tracks to which local capture queue a corresponding instruction should be written back to, and a latency value that tracks when the results of an instruction should be ready for output.

[0076] In unprotected mode and when the instruction enters the E1 stage, the value of the lifetime tracking value corresponds to the expected number of cycles needed for functional unit 808 to process the instruction. For each clock cycle that the processor is not stalled, these lifetime tracking values can be adjusted, e.g., by decrementing the value. The lifetime tracking value can stall at any time the pipeline stalls. This scoreboard helps enable interrupt / event recovery by tracking where values from local unit capture queue 804 should be restored to. When the lifetime tracking value equals 0, the results of the instruction are ready to be written back to the output register.

[0077] If the instruction is interrupted before the lifetime tracking value has become zero, the instruction results and their corresponding lifetime tracking values can be saved to maintain correct execution when returning from the interrupt. For example, upon receiving an interrupt, scoreboard 802 can stall the pipeline that has been executed and any portion of the MPY32 instruction, and the state of the pipeline stages can be saved to local unit capture queue 804, and then to central capture queue 806. For example, the corresponding lifetime tracking values can also be saved in the writeback queue. The interrupt can then be processed, and after the interrupt is handled, any results and state related to the MPY32 instruction saved in local unit capture queue 804 or central capture queue 806 can be restored. Processing of the MPY32 can then be resumed based on the restored lifetime tracking values.

[0078] In some cases, an instruction in the first phase of execution (e.g., the El phase) will not be recovered in the first phase. Rather, the instruction can be reloaded into the first phase and run upon processing recovery. For example, in some cases, the pipeline can receive two instructions as a dual instruction at a time. In this case, the results of the two instructions can be output in the same cycle. As a more specific example, a SUB and LDD command can be issued together as a dual instruction. The two commands both enter the El phase and are processed. The LDD command can experience a page fault when attempting to access a memory address to output the contents of the memory address, and raise a page fault exception. Since the SUB command is a single cycle command, the result of the SUB command is ready to be output at the end of the El phase. This output can be saved to the central capture queue 806, since in some cases the El phase can not have an associated local capture queue. Execution then proceeds to the exception handler. After the exception handler is complete, execution returns to the main process. Since the first execution of the LDD command resulted in an exception, the LDD command needs to be re-executed to obtain the desired result. Then, when the SUB and LDD dual instruction is reloaded into El and re-executed, the result of the SUB command stored in the central capture queue 806 can be discarded. In some cases, a multi-cycle command can be issued as part of a dual instruction, such as with a LDD command. Then, before the exception handler executes, the multi-cycle command can proceed to E2 and will be allocated a write back queue entry. Typically, a write back queue entry is made whenever there is an item stored in a local capture queue. The multi-cycle command can also be rolled back into El and re-executed with a LDD instruction. However, rolling back the execution state can require tracking more instruction results than the number of pipeline phases. In some cases, the number of registers in the write back queue can exceed the number of pipeline phases to handle corner cases around tracking instructions that exit the El phase to the E2 phase and generate output but are to be rolled back to the El phase.

[0079] In some cases, if execution of a multi-cycle instruction has started at the time the interrupt is received, such as if the MPY32 instruction is in the E2 to E4 phases, the multi-cycle instruction can be executed to completion and the results stored in the central capture queue 806 via the local unit capture queue 804. After the interrupt is handled, the stored results from the multi-cycle instruction are recovered from the central capture queue 806 to the local unit capture queue 804 for output.

[0080] In some cases, the local unit capture queue 804 and the central capture queue 806 can be omitted, and instead, a save memory or register can be used to enable interrupt handling in unprotected mode. In this case, if an interrupt is received after execution of the instruction has begun (e.g., in the E2 to E4 stages), the instruction can be executed to completion and the results stored in the save memory. After the interrupt is handled, the stored results are then written to the output register. If an interrupt is received before execution of the instruction begins (e.g., in the El stage), the instruction is reloaded after the interrupt is handled. If the instruction passes through the El stage and moves to E2, a local unit capture queue can be allocated for the instruction.

[0081] According to certain aspects, the information in the writeback queue can also include a latency value to help track the lifetime of the associated instruction. The latency value can be initialized based on an expected number of processor cycles required for the associated instruction to execute. For each clock cycle, the latency value can be adjusted, e.g., by decrementing the value, regardless of whether the pipeline is stalled. If there is no pipeline stall, both the lifetime tracking value and the latency value will expire at the same time, and the results of the instruction can be written to the output register file. If the pipeline is stalled, as described above, adjusting the lifetime tracking value associated with the instruction can be stalled. However, if the instruction passes through the El stage, execution of the instruction continues until the instruction completes. In this case, the latency counter will reach its expiration value (e.g., zero) before the lifetime tracking value reaches its expiration value (e.g., zero), and the results of the instruction can be captured in the local unit capture queue. In the case that the output has been captured by the local unit capture queue, the writeback queue entry can continue to track the output until the lifetime reaches its expiration value. When the lifetime value reaches its expiration value and the pipeline is not stalled, the output can be transferred from the local unit capture queue to the output register file specified by the instruction.

[0082] According to certain aspects, scoreboard 802 can also track outstanding memory load operations, such as those that result from unexpected events in the memory system (e.g., cache misses). In certain cases, scoreboard 802 can track up to a fixed number (e.g., up to eight) outstanding loads that have not completed prior to stalling the pipeline due to L1 D read data not being returned. There are at least three general cases in which the pipeline can stall due to memory load situations. First, in protected mode, if the destination of a load instruction is read as an operand to a subsequent instruction before the L1 D data cache can return the data, the pipeline stalls until the L1 D data cache returns the data. Second, in protected or unprotected mode, if the destination of a load instruction is read as an operand to an instruction and the L1 D data cache indicates that it will not have the data before the 4-cycle L1 D cache latency, the pipeline will stall. Third, if the processor has sent eight load instructions and no data has been returned for any of them, when it encounters the next load instruction, the pipeline will stall, provided it has not already stalled for any of the above reasons.

[0083] Using scoreboard 802 to track memory load behavior helps allow the processor to accept data returns from the memory system in any order. In certain cases, the processor can be configured to send a transaction identifier (ID) with each load instruction, and the L1 D can use the load data return to correspond to the transaction ID. Scoreboard 802 can also allow the compiler to further hoist load instructions up in the schedule and hide L1 D cache miss penalties when the compiler knows it has enough other work for the processor. Additionally, scoreboard 802 allows the L1 D data cache to support hit-under-miss behavior, resulting in possible performance improvements for code that has a mix of load that can miss (e.g., large database item lookups) and load that can hit (e.g., stack accesses).

[0084] According to certain aspects, the central capture queue 806 can hold the contents of the local unit capture queue 804, for example, when an interrupt or exception event occurs. The central capture queue 806 can include one or more save registers Q0-Q4 to delay updates to processor registers upon detection of one or more instruction write back issues that should occur while the instruction is leaving the E1 execution stage. For example, during execution of a load or store instruction, a page fault as part of a branch to a page fault handling service can be detected by a micro translation lookaside buffer (μTLB). Typically, the μTLB translates load / store instruction addresses to physical mappings. In the event that a virtual to physical address mapping for a particular memory access instruction cannot be found, the μTLB triggers a page fault in the E1 execution stage. The load / save instruction is then placed into the central capture queue. In protected mode, all instructions prior to the load / save instruction that caused the page fault complete normally. In unprotected mode, if the instructions prior to the load / save instruction that caused the page fault have not reached their normal write back cycle before the page fault is detected by the μTLB, the results of such instructions will be saved in the central capture queue or local unit capture queue for output to the register file after the page fault is resolved. After the page fault is resolved, for example, after the correct page translation entry is located, the load / save instruction will be resumed and execution using the correct page translation entry will resume. In certain cases, a correctable issue with execution of an instruction can be detected when the instruction is in the E2 stage of execution. If the processor determines that the instruction has a correctable issue in the E2 stage, the register file updates delayed in the central capture queue 806 will be returned to the local unit capture queue so that they can be saved when the processor passes execution to an exception handling program.

[0085] According to certain aspects, in protected mode, when an interrupt is received, execution of instructions that were in the pipeline before the interrupt was executed normally, followed by the interrupt, and then the remaining instructions are executed. Since the program expects the processor to insert delays as needed, interrupt handling is straight forward. In unprotected mode, when an interrupt is attempted to be executed in the middle of executing application code, it will likely break the instruction schedule when the instruction schedule is handled by the application or the compiler itself. A local unit capture queue can be used to help resolve such potential scheduling issues. When operating in unprotected mode, when an interrupt is received, the contents of the pipeline of the functional unit handling the interrupt can be written to the local unit capture queue. The interrupt is then handled, and the pipeline is restored after the interrupt is handled. However, the capture queue can be used for data hazards and load / store out-of-order completion, as well as handling interrupts. In some cases, the pipeline can be operating in unprotected mode before the interrupt is received, but after the interrupt is received, but before control is returned to the application code, the pipeline is switched to protected mode, for example by an interrupt handling program. Since the local unit capture queue can be used when operating in protected mode, the pipeline data in the local unit capture queue can be offloaded to, for example, memory. This memory space can be space in cache memory, for example in an L1, L2, or L3 cache, or in an on-die static random access memory (SRAM) cache.

[0086] When it is known that the local unit capture queue needs to be offloaded, for example when an interrupt is received while operating in unprotected mode, the processor can help pre-write an allocated block of memory for the contents of the local unit capture queue in memory space. Each executing task in the processor is associated with an event context save pointer (ECSP) that points to memory space. When the original task is interrupted by an interrupt or another higher priority task, the state of the pipeline registers of the functional unit are saved to the local unit capture queue, and then copied to the block of memory based on the ECSP-A that points to the block of memory. The functional unit then begins executing the interrupt task, and rewrites the ECSP to ECSP-B that is associated with the interrupt task. During execution of the interrupt task, the local unit capture queue is used to complete the interrupt task. When the interrupt task is complete, the original task is reloaded, and the ECSP is rewritten based on ECSP-A. Based on ECSP-A, the state of the pipeline registers are copied to the local unit capture queue, and then to the pipeline registers. Execution of the original task resumes at the point where it stopped previously.

[0087] Figure 9 An example functional unit, capture queue, and scoreboard complex 900 according to aspects of the present description is illustrated. As shown, a functional unit 902 of complex 900 is coupled to a capture queue 904 and a scoreboard 906 from a Figure 8The M functional unit 808B corresponds to the functional unit 902. The functional unit 902 includes four pipe stages, and other functional units can include more or fewer pipe stages. Each pipe stage of the functional unit 902 takes one clock cycle to complete. Each instruction can take a different number of cycles to process. For example, a first instruction can take two cycles to complete, and thus output from the E2 pipe stage. Each functional unit can generate a single write to the output register file 914 per clock cycle via the result bus 916. The local unit capture queue 904 helps track the pipeline register contents in the corresponding functional unit. Typically, there can be one local unit capture queue 904 per functional unit. Each pipe stage that can generate a result, here El, E2, and E4, can be coupled to one or more MUXs 906A-C and capture queue registers 908A-C of the local unit capture queue 904. Connecting the pipe stages to multiple capture queue registers helps handle long series of instructions. For example, there can be a series of instructions in the pipeline that will all attempt to write to the output register in the same clock cycle, for example, a four cycle instruction, followed by a three cycle, then a two cycle, and a one cycle instruction. In this case, the four cycle instruction will be written to the output register, and the three cycle, two cycle, and one cycle instructions will be stored in the capture queue registers 908A-C.

[0088] The local unit capture queue 904 can operate in conjunction with a scoreboard 910. The scoreboard 910 is coupled to the MUXs 906A-C along with the central capture queue 918, and the capture queue registers 908A-C are clock gated via bus 912. The scoreboard 910 maintains a set of registers that can help track whether a functional unit is working on producing a result. If the corresponding register of a functional unit is working on producing a result as a write back value of the corresponding register, the bit corresponding to the register is high. All functional unit scoreboard tracking registers write back results are then ORed together at the top level to combine all register usage per cycle. The scoreboard 908 can then make a set of comparisons. In some cases, the scoreboard 908 can compare each read operand of each functional unit to detect potential read-after-write hazards in protected mode. For example, if the.N scr1 operand is register Al, and Al will be written back by the.M unit in two cycles,.N will detect if another instruction operand attempts to read Al, and stall the instruction operand reading Al at the El stage until the corresponding bit is set low. The corresponding bit can also be compared to the write address of each unit to detect write-after-write hazards in protected mode. For example, if another functional unit (e.g.,.L) is writing to Al, then Al will be written back by the.M functional unit in three cycles (which is two cycles after the.L functional unit has worked on producing the Al write back value). Hazard logic is then used to load the local capture queue of the.L functional unit until the.M completes writing Al and the corresponding bit is set low. The local capture queue of the.L functional unit will then unload the Al value from its storage and put it on the output of.L.

[0089] Figure 10 An example capture queue register bit field 1000 is illustrated in accordance with some aspects. The fields shown, their order, and field sizes can vary, and as Figure 10 The field illustrated in FIG. 10B is one example capture queue register bit field. Bit fields 1002 and 1004 illustrate two example data formats for a capture queue and a write back queue. In accordance with certain aspects, the information from block 1006 is stored in the write back queue, and the information from block 1008 is stored in the capture queue. In this example of a write back queue, V indicates whether a bit is valid, DV indicates whether a write is updating a main register file, PV indicates whether this write is updating a predicate register file, RFNUM encodes which register file is being written, RFADDR encodes a register file address, RFPADDR encodes a predicate register file address, and LIFE encodes a lifetime tracking value. For the capture queue, FP state indicates a predicate file state, and DATA indicates stored data.

[0090] As Figure 11As explained in the Background, the capture queue structure also helps enable fast mode switching between protected mode and unprotected mode, and vice versa. Previously, certain processors could switch between, for example, unprotected mode and protected mode, but would typically stall instructions after a switch command until all valid instructions were completed. The capture queue helps enable switching from unprotected mode to protected mode, and vice versa, without clearing the pipeline or even stalling in some cases. For example, when switching from unprotected mode to protected mode, the age of any instructions already present in the pipeline can be set to less than 0, e.g., -1, meaning that the corresponding instruction should already be committed to the register file. As described above, the hazard logic associated with protected mode then becomes active. In Figure 10 In cycle 1 of Figure 1, the processor pipeline executing the instructions explained executes in unprotected mode. At cycle 4, a PROT command is executed in E1 and the pipeline is switched to protected mode. The age tracking value for the MPY is then set to -1. The age tracking value for the ADD command is then set to the value normally associated with the ADD command, as execution of the command has not yet begun. If the ADD command utilizes the A0 register output to by the MPY32 command, then execution of the ADD command proceeds normally as described above. In the case where the ADD command does not utilize the same register as the MPY32 command, then the ADD command can be executed immediately after the PROT command without stalling the pipeline.

[0091] Figure 12 An example circuit for age tracking 1200 is explained in accordance with some aspects. After an instruction is read in the DC2 stage and passed from the DC2 register 1202 to the E1 stage, a write back queue 1210 is allocated for the instruction. A counter 1204 tracks which write back queue slots WBQ 0 through WBQ 4 should be used next and generates a pointer to the next write back queue slot and this pointer id decoded in a decoder 1206 which converts the pointer to an address on the write back queue bus. The write back queue slots are allocated in a round robin order, e.g., write back queue slot WBQ 0 is allocated first, then WBQ 1 is allocated, and so on to the last write back queue slot, here WBQ 4. After the last write back queue slot is allocated, the allocation of the next write back queue slot returns to the first write back queue slot and the next write back queue slot to be allocated is WBQ 0. The write back queue slots can be allocated in a round robin order to help ensure that if there are multiple writes back in the same cycle, the allocation of write back queue slots will occur in a deterministic manner. The data in the write back queue slots can be associated with corresponding local unit capture queue slots CQ 0 through CQ 3 via a cell scheduler 1208.

[0092] The local unit capture queue slot associated with the instruction can be assigned to the write back queue slot entry on a lowest entry available basis. In some cases, the local unit capture queue slot number can be decided at the time of instruction forwarding from the DC2 stage to the El stage and saved in memory while the instruction is in the El stage. When the instruction is forwarded from the El stage to the E2 stage, the local unit capture queue slot number can be written into the local unit capture queue number field of the associated write back queue. The local unit capture queue number of the write back queue and any unit capture queue slot number assigned in the El stage can be combined to build a vector of all currently used local unit capture queue slots. The next available local unit capture queue slot for use is the lowest numbered local unit capture queue slot that is not currently in use.

[0093] According to certain aspects, certain commands can not return a result within a fixed number of cycles. These commands can be referred to as variable latency commands. Examples of variable latency instructions can include LOAD commands as well as DIV and MOD commands. In some cases, variable latency commands can be divided into two different types, a first type being memory operations (e.g., LOAD commands) and a second type being commands where the amount of time required to complete the command varies based on the operands of the command operation (e.g., divide or modulo commands). The first type of variable latency command can generally be used to retrieve data from a memory system. In some cases, the memory system can return the result in any order and / or size. The time to return the data can vary due to, for example, cache misses, memory bank conflicts, cache maintenance operations, etc. Similarly, the second type of variable latency command can take up to 64 cycles to complete, but the exact number of cycles can vary, for example, based on the values of the divisor and the dividend. Lifetime tracking of variable latency instructions can be handled by modifying the write back queue.

[0094] In some cases, the first type of variable latency command can be handled in a similar manner to the way other multi-cycle instructions are handled using certain modifications. First, the mapping between writeback queue slots and local unit capture queue slots can be modified to have a one-to-one mapping, rather than having more writeback queue slots than local unit capture queue slots. In addition, instead of using a circular buffer to select which writeback queue slot to use next, the next writeback queue slot can be selected based on the lowest entry available and the local unit capture queue available. Upon issuance of a LOAD command, the selected writeback queue slot and local unit capture queue slot number can be passed to the memory system as a command ID (CID). Then, when the memory system returns the requested portion of data from the LOAD command, the portion can be returned with the associated CID. The returned portion can be assembled in the appropriate portion of the writeback queue. The memory system can also return an indication (e.g., RLAST) that the associated portion of requested data being returned is the final portion. Upon receiving this indication, the LOAD data can be output from the writeback buffer.

[0095] Figure 13 An example circuit for variable latency lifetime tracking 1300 is illustrated in accordance with some aspects. In some cases, a ready counter in the writeback queue 1306 and a dedicated writeback queue slot 1302 as well as a dedicated local unit capture queue slot 1304 in the local unit capture queue 1308 can also be used to handle the second type of variable latency command. If the dedicated writeback queue slot 1302 is occupied or active, any new second type command can stall in the El stage until the current variable latency command has completed. In some cases, variable latency commands are not pipelined, and a functional unit can execute a single variable latency command at a time. In some cases, in unprotected mode, the second type of command is defined to take zero or one cycle to complete. Since the functional unit is occupied to process the variable latency command for several cycles, the next instruction can then stall and execute after the second type command completes. According to some aspects, in cases where a dedicated writeback queue 1302 and local unit capture queue 1304 are used to execute a variable latency command, some functional units can be configured to support the second type of command, while other functional units can not support the second type of command.

[0096] Figure 14is a flowchart 1400 illustrating a technique for executing a plurality of instructions by a processor according to some aspects. At block 1402, a first instruction for execution on an instruction execution pipeline is received. As an example, a non-variable latency instruction can be received by a processor for execution. At block 1404, a first latency value can be determined based on an expected amount of time required to execute the first instruction. For example, the instruction can be associated with an expected number of processor cycles required to execute the instruction associated with the execution. The latency value can be assigned based on this expected number of processor cycles. At block 1406, the first latency value is stored in a write back queue associated with the first instruction. The write back queue stores information associated with the execution of instructions. For example, the write back queue can be a set of processor registers that can store information associated with the execution of instructions. The write back queue can be associated with a local unit capture queue slot. At block 1408, execution of the first instruction on the instruction execution pipeline can be started. At block 1410, the latency value can be adjusted based on an amount of time that has elapsed since the execution of the first instruction was started. For example, the latency value associated with the execution of the instruction can be adjusted at each processor clock cycle. At block 1412, a first result of the first instruction based on the latency value can be output. At block 1414, a second instruction for execution on the instruction execution pipeline is received. At block 1416, the second instruction is determined to be a variable latency instruction. Examples of variable latency instructions include, but are not limited to, memory operations, division, and modulo operations. At block 1418, an indication in the write back queue is stored that a second result of the second instruction is not ready. As an example, the latency tracking value can be replaced with a data ready indicator that indicates whether the second instruction has completed execution. At block 1420, execution of the second instruction on the instruction execution pipeline is started. If a third variable latency instruction for execution on the instruction execution pipeline is received while the second instruction is executing, the third instruction will be stalled based on the data ready indicator. If a third instruction for execution on the instruction pipeline is received while the second instruction being executed is not a variable latency instruction, but the third instruction utilizes a memory location that will be used by the second instruction, the third instruction will also be stalled based on the data ready indicator. At block 1422, based on a determination that the execution of the second instruction has completed, the ready value is updated to indicate that the second result is ready. For example, a signal can be received with a portion of data requested from memory that indicates that the portion of data is the last portion of data requested. The data ready indication in the write back queue can be updated based on the signal. Similarly, after a division or modulo operation is completed, the data ready indication in the write back queue can be updated. At block 1424, the second result is output. For example, the result can be available in an appropriate output register. Execution of the stalled third instruction can then be started.

[0097] In this description, the term "couple" or "couples" means either a direct or indirect wired or wireless connection. Thus, if a first device couples to a second device, that connection can be through a direct connection or through an indirect connection via other devices and connections. The recitation "based on" means "based, at least in part, on." Thus, if X is based on Y, X can be a function of Y and any number of other factors.

[0098] The above discussion illustrates the principles and various embodiments of the present description. Many changes and modifications will become apparent to those skilled in the art once the above description is fully appreciated. The following claims encompass all such changes and modifications.

[0099] In the drawings, like reference numerals refer to like elements throughout.

[0100] Modifications are possible in the described embodiments, and other embodiments are possible within the scope of the claims.

Claims

1. A method for executing a plurality of instructions by a processor, the method comprising: Receives the first instruction to be executed in the instruction execution pipeline; Whether to store the first delay value or the first ready value of the first instruction into the write-back queue is determined based on whether the first instruction has a non-variable delay or a variable delay. Since the first instruction has a non-variable delay: Before executing the first instruction, the first delay value is determined based on the expected amount of time required to execute the first instruction; Store the first delay value in the write-back queue; The first instruction is executed on the instruction execution pipeline; The first delay value is adjusted based on the amount of time elapsed since the first instruction began execution; as well as Output the first result of the first instruction based on the first delay value; Receive a second instruction for execution on the instruction execution pipeline; Whether to store the second delay value or the second ready value of the second instruction into the write-back queue is determined based on whether the second instruction has a non-variable delay or a variable delay. as well as Since the second instruction has a variable delay: The write-back queue stores a second ready value indicating that the second result of the second instruction is not ready; The second instruction is executed on the instruction execution pipeline; The second ready value is updated based on the determination that the execution of the second instruction has been completed to indicate that the second result is ready; and Output the second result.

2. The method of claim 1, wherein the second instruction includes a memory operation.

3. The method of claim 2, wherein the memory operation includes loading data from memory, and the method further includes: Receive one or more portions of the data from the memory; When one or more portions are received, the one or more portions of the data are assembled in the write-back queue; and The data is output after the data is assembled from one or more portions of the data.

4. The method according to claim 1, wherein the second instruction includes a division or modulo instruction.

5. The method of claim 4, wherein the second ready value is stored in a dedicated write-back queue.

6. The method of claim 1, wherein the expected time amount is based on the number of processor loops in which the corresponding instruction can be completed.

7. The method of claim 1, further comprising: Before the execution of the second instruction is completed, a third instruction for execution on the instruction execution pipeline is received; and The execution of the third instruction is suspended until the execution of the second instruction has been completed.

8. The method of claim 7, wherein the suspension of execution of the third instruction is based on the second ready value.

9. A processor comprising: The instruction execution pipeline has multiple pipeline stages; as well as The pipeline circuit system is configured to: Receive a first instruction for execution on the instruction execution pipeline; Whether to store the first delay value or the first ready value of the first instruction into the write-back queue is determined based on whether the first instruction has a non-variable delay or a variable delay. Since the first instruction has a non-variable delay: The first delay value is determined based on the expected amount of time required to execute the first instruction; Store the first delay value in the write-back queue; The first instruction is executed on the instruction execution pipeline; The first delay value is adjusted based on the amount of time elapsed since the first instruction began execution; as well as Output the first result of the first instruction based on the first delay value; Receive a second instruction for execution on the instruction execution pipeline; Whether to store the second delay value or the second ready value of the second instruction into the write-back queue is determined based on whether the second instruction has a non-variable delay or a variable delay. as well as Since the second instruction has a variable delay: The write-back queue stores a second ready value indicating that the second result of the second instruction is not ready; The second instruction is executed on the instruction execution pipeline; The second ready value is updated based on the determination that the execution of the second instruction has been completed to indicate that the second result is ready; and Output the second result.

10. The processor of claim 9, wherein the second instruction includes a memory operation.

11. The processor of claim 10, wherein the memory operation includes loading data from memory, and wherein the pipeline circuitry is further configured to: Receive one or more portions of the data from the memory; Upon receiving one or more portions, assemble the one or more portions of the data in the write-back queue; and The data is output after the data is assembled from one or more portions of the data.

12. The processor of claim 9, wherein the second instruction includes a division or modulo instruction.

13. The processor of claim 12, wherein the second ready value is stored in a dedicated write-back queue.

14. The processor of claim 9, wherein the expected time amount is based on the number of processor cycles in which the corresponding instruction can be completed.

15. The processor of claim 9, wherein the pipeline circuitry is further configured to: Before the execution of the second instruction is completed, a third instruction for execution on the instruction execution pipeline is received; and The execution of the third instruction is suspended until the execution of the second instruction has been completed.

16. A processing system comprising: Memory; as well as Processor, comprising: The instruction execution pipeline has multiple pipeline stages; and The pipeline circuit system is configured to: Receive a first instruction for execution on the instruction execution pipeline; Whether to store the first delay value or the first ready value of the first instruction into the write-back queue is determined based on whether the first instruction has a non-variable delay or a variable delay. Since the first instruction has a non-variable delay: The first delay value is determined based on the expected amount of time required to execute the first instruction; Store the first delay value in the write-back queue; The first instruction is executed on the instruction execution pipeline; The first delay value is adjusted based on the amount of time elapsed since the first instruction began execution; and Output the first result of the first instruction based on the first delay value; Receive a second instruction for execution on the instruction execution pipeline; Whether to store the second delay value or the second ready value of the second instruction into the write-back queue is determined based on whether the second instruction is a non-variable delay instruction or a variable delay instruction; and Since the second instruction has a variable delay: The write-back queue stores a second ready value indicating that the second result of the second instruction is not ready; The second instruction is executed on the instruction execution pipeline; The second ready value is updated based on the determination that the execution of the second instruction has been completed to indicate that the second result is ready; and Output the second result.

17. The processing system of claim 16, wherein the second instruction includes a memory operation.

18. The processing system of claim 17, wherein the memory operation includes loading data from the memory, and wherein the pipeline circuitry system is further configured to: Receive one or more portions of the data from the memory; Upon receiving one or more portions, assemble the one or more portions of the data in the write-back queue; and The data is output after the data is assembled from one or more portions of the data.

19. The processing system of claim 16, wherein the second instruction includes a division or modulo instruction.

20. The processing system of claim 19, wherein the second ready value is stored in a dedicated write-back queue.

Citation Information

Patent Citations

  • Processing long-latency instructions in a pipelined processor

    US20120246451A1

  • Apparatus for sampling instruction execution information in a processor pipeline

    US6195748B1