Improved Keccak execution resilient to physical side channel attacks

Abstract

An improved Keccak execution that is resilient to physical side channel attacks is described. In some examples, a Keccak round data path includes: a first path including a theta step, a rho step, a pi step, and an iota step to process a masked version of a 1600-bit input state; a second path comprising a [theta] step, a [rho] step, and a [pi] step to process the masked 1600-bit input state; and a masked chi step shared by the first path and the second path.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to Keccak processing, and more particularly to an improved Keccak implementation that is resilient to physical side-channel attacks. Background Art

[0002] Cryptographic hashing is one of the most basic operations for providing data integrity and authentication and is used in a variety of platforms. Secure hash algorithm 3 (SHA3) is a relatively new National Institute of Standards and Technology (NIST) standard cryptographic hashing operation and has become an increasingly popular hashing algorithm for computing digests of large images / data for classical signature schemes (e.g., elliptic curve digital signature algorithm (ECDSA) and Rivest-Shamir-Adleman (RSA) schemes), post-quantum signature schemes (e.g., hash-based signatures), and certain SHA3-derived functions (e.g., KECCAK message authentication code (KMAC), customizable secure hash algorithm and KECCAK (cSHAKE), TupleHash, and ParallelHash). SHA3 ​​is the fundamental building block of all post-quantum digital signatures (CRYSTALS-Dilithium, Falcon, SPHINCS+) as well as the key encapsulation mechanism selected by NIST for an upcoming standard (CRYSTALS-Kyber). Physical side channels (e.g., power consumption, electromagnetic radiation, photon emission) leak sensitive inputs or outputs during SHA3 execution, regardless of whether its SW is executed or implemented on dedicated HW. These side channels of SHA3 implementations are considered a fundamental threat to the deployment of new post-quantum cryptography (PQC) algorithms. Summary of the invention

[0003] One aspect of the present disclosure provides a device comprising: a storage device for storing a 1600-bit input state; a Keccak-round data path coupled to the storage device, the Keccak-round data path comprising at least: a first path comprising a θ step, a ρ step, a π step, and an ι step to process a masked version of the 1600-bit input state; a second path comprising a θ step, a ρ step, and a π step to process a masked 1600-bit input state; and a masked χ step, the masked χ step being shared by the first path and the second path.

[0004] One aspect of the present disclosure provides a system comprising: a memory for storing a 1600-bit input state; an execution circuit comprising: a Keccak-round data path coupled to the memory, the Keccak-round data path comprising at least: a first path comprising a θ step, a ρ step, a π step, and an ι step to process a masked version of the 1600-bit input state; a second path comprising a θ step, a ρ step, and a π step to process a masked 1600-bit input state; and a masked χ step, the masked χ step being shared by the first path and the second path; and other SHA3 circuits.

[0005] One aspect of the present disclosure provides a method comprising: splitting a 1600-bit input state into two random 1600-bit states; independently performing a linear Keccak operation on the two 1600-bit random states; combining the outputs of the linear Keccak operation on the two random states in a nonlinear χ step calculation to produce an updated value; and performing an ι operation on the output of the nonlinear χ calculation. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Various examples according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0007] Figure 1 An example of the steps of a round of Keccak processing is illustrated.

[0008] Figure 2 An example of a Keccak state array is illustrated.

[0009] Figure 3 An example of an architecture for theta steps is illustrated.

[0010] Figure 4 An example in which the ρ step (rho step) and the π step (pi step) are performed together is illustrated.

[0011] Figure 5An example of a linear feedback shift register round counter is illustrated.

[0012] Figure 6 An example of a combined χ step (chi step) and ι step (iota step) is illustrated.

[0013] Figure 7 An example of computing hardware that processes Keccak instructions is illustrated.

[0014] Figure 8 An example of an execution circuit for Keccak instruction processing is illustrated.

[0015] Fig. 9 An example of a Keccak1600 round data path is illustrated.

[0016] Fig.10 A state transition diagram is illustrated.

[0017] Fig.11 Examples of normal χ and masked χ steps are illustrated.

[0018] Fig.12 An example method for processing Keccak instructions performed by a processor is illustrated.

[0019] Fig.13 An example of a method performed by a processor to execute Keccak instructions using masking is illustrated.

[0020] Fig.14 An example computing system is illustrated.

[0021] Fig.15 A block diagram of an example processor and / or system on a chip (SoC) that may have one or more cores and an integrated memory controller is illustrated.

[0022] Fig.16 is a block diagram illustrating a computing system 1600 configured to implement one or more aspects of the examples described herein.

[0023] Fig.17A An example of a parallel processor is illustrated.

[0024] Fig. 17B An example of a block diagram of a partition unit is illustrated.

[0025] Fig. 17C An example of a block diagram of a processing cluster within a parallel processing unit is illustrated.

[0026] Fig.17D An example of a graphics multiprocessor is illustrated, wherein the graphics multiprocessor is coupled with a pipeline manager of a processing cluster.

[0027] 18A to 18C Additional graphics multiprocessors according to examples are illustrated.

[0028] Fig.19 A parallel computing system 1900 according to some examples is illustrated.

[0029] FIG. 20A to FIG. 20B A hybrid logical / physical view of a factorized parallel processor according to examples described herein is illustrated.

[0030] 21(A) is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example.

[0031] 21(B) is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example.

[0032] Fig. 22 Examples of execution unit circuits such as execution unit circuits are illustrated.

[0033] Fig.23 is a block diagram of a register architecture according to some examples.

[0034] Fig.24 An example of the instruction format is illustrated.

[0035] Fig.25 An example of the addressing information field is illustrated.

[0036] Fig.26 An example of the first prefix is ​​illustrated.

[0037] 27(A) to 27(D) illustrate examples of how to use the R, X, and B fields of the first prefix.

[0038] 28(A) to 28(B) illustrate examples of the second prefix.

[0039] Fig.29 An example of the third prefix is ​​illustrated.

[0040] FIG. 30A to FIG. 30B Thread execution logic including an array of processing elements employed in a graphics processor core according to examples described herein is illustrated.

[0041] Fig.31 Additional execution units according to examples are illustrated.

[0042] Fig.32 is a block diagram illustrating a graphics processor instruction format 3200 according to some examples.

[0043] Fig.33is a block diagram of another example of a graphics processor.

[0044] Fig.34A is a block diagram illustrating a graphics processor command format according to some examples.

[0045] Fig.34B is a block diagram illustrating a graphics processor command sequence according to an example.

[0046] Fig.35 is a block diagram illustrating converting binary instructions in a source ISA to binary instructions in a target ISA using a software instruction converter according to an example.

[0047] Fig.36 is a block diagram illustrating an IP core development system 3600 that can be used to fabricate an integrated circuit to perform operations according to some examples. DETAILED DESCRIPTION

[0048] The present disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for Keccak processing.

[0049] All current secure communication protocols (such as Transport Layer Security (TLS), Internet Key Exchange (IKE), Quick UDP Internet Connections (QUIC), Internet Protocol Security (IPsec), etc.) will need to be upgraded with PQC to protect against quantum attacks. Unfortunately, this upgrade comes with significant overhead. For example, 18%-91% fewer connections per second.

[0050] Candidates for PQC are biased towards the computationally intensive SHA3 / Keccak functions. For example, Kyber and Dilithium spend more than 50% of their computation on Keccak. Moreover, for embedded cores, SHA3 execution is latency intensive due to its large state size, which makes the deployment of PQC schemes even more difficult. Some existing methods to speed up SHA3 use several instructions (e.g., in some ARM cores using BCAX, EOR3, RAX1, and XAR), which results in a latency of more than 1000 cycles for 24 rounds of Keccak1600 execution.

[0051] An attacker could potentially exploit the computation of the first few rounds of Keccak (SHA3) to reveal the secret input state via power / electromagnetic (EM) measurements. The prior art computation of all 24 rounds of Keccak uses a back-to-back combined data path to reduce the signal-to-noise ratio (SNR) by mixing the signal of the first 3 sensitive rounds with the noise of the remaining 21 rounds. Unfortunately, this has a significant 24x area overhead, which is a bottleneck for deploying PQC within limited die area and power budgets.

[0052] This paper details examples for improved Keccak hardware implementation. These examples are area efficient methods and randomize the signal value (S) during at least the first 3 rounds of computation on the actual secret input state to remove the correlation between the input state and the power / EM measurement.

[0053] In some examples, the execution data path of the Keccak instruction has a 1600-bit input and a 1600-bit output, and performs masking of various aspects of the Keccak scheme. The Keccak round function involves protected linear and nonlinear steps, which in some examples are as follows:

[0054] 1) Split the 1600-bit input state into two random 1600-bit states;

[0055] 2) Perform linear operations (θ, ρ, and π) independently on two random states;

[0056] 3) Combine two random states in a nonlinear χ calculation and generate their updated values;

[0057] 4) repeating this operation 24 times in multiple rounds (e.g., all rounds); and

[0058] 5) XOR the last two random states to get the final 1600-bit state output.

[0059] The masked design of the round-based Keccak1600 engine provides robustness against physical (power, EM, photon emission) side-channel attacks. This innovation protects the PQC scheme from multiple attacks that may be applied to the underlying SHA-3 implementation. The proposed solution is efficient without requiring new random values ​​for successive executions.

[0060] In some examples, a single instruction includes source addressing information for input states and destination addressing information for output states. Processing of the instruction causes a load from the source memory address to a register and a store of the result from the register to the destination memory address.

[0061] In some examples, loading to and storing from registers is accomplished using existing load / store instructions. For example, four loads may be used to load a state into four 512-bit registers where the state is to be stored, and four stores may be used to write the state to memory.

[0062] In some examples, when there are one or more message blocks, the software can load the message into another set of wide registers and perform a wide XOR operation with the message and the last output Keccak state to calculate the next input state. The software can then execute the next Keccak instruction. At the end of all message blocks, the software can use a wide store instruction to store the final state / digest to the desired destination address.

[0063] Before detailing improvements to the Keccak process, exemplary aspects of the Keccak process are provided. Figure 1 An example of the steps of a round of Keccak processing is illustrated. The block transformation f (in SHA-3, Keccak-f

[1600] ) is a permutation using XOR, AND, and NOT logical operations. It should be noted that the gates themselves can be composed of NAND, NOT, and / or NAND / NOT gates. Keccak is defined as a power of 2 word (w) size, where w = 2 l In some SHA-3 methods, 64-bit words (l=6) are used.

[0064] The state of Keccak can be viewed as a 5x5xw array of bits. Figure 2 An example of a Keccak state array is illustrated. This 2D state of Keccak can be represented as: x=0..4 and y=0..4, and for internal memory representation, the 2D state is converted to a 1D index i=5y+x.

[0065] The indexing algorithm in Keccak is performed modulo 5 for the first two dimensions of the state and modulo w for the third dimension. The permutation processed by Keccak consists of 12+21 rounds of five steps.

[0066] Note that this illustration can be used for both the initial round (eg, when round=1 101 ) and subsequent rounds (eg, when round>0).

[0067] The theta step 103 modifies the input state variable A as follows:

[0068]

[0069]

[0070]

[0071] Figure 3An example of an architecture for theta steps is illustrated. In the example shown, each block shown is 64 bits long. The A blocks are each a subset of the 1600-bit input state variables. A[i,j] maps to A[5*i+j], and the variable E is used to represent the modified state A as defined in equation (3) above. In some examples, the architecture is implemented with a five-input XOR gate and a two-input XOR gate. Further, in some embodiments, bit rotation (Rot-1, i.e., rotation by 1 bit) is implemented by rewiring without requiring any logic gates.

[0072] The example architecture performs a first bitwise XOR operation on corresponding groups of input blocks (e.g., A0, A1, A2, A3, A4) to generate an intermediate output block (e.g., (C0)). A second bitwise XOR operation is performed on each first intermediate block (e.g., C0) and another first intermediate block rotated (e.g., C2 rotated by 1 bit) to generate a second intermediate block (e.g., D1). In the example shown, the first intermediate blocks operated by the second bitwise XOR operation are two indexes away from each other and are each one index away from the resulting second intermediate block (e.g., the XOR operation performed on C0 and the rotated C2 produces D1). A third bitwise XOR operation is performed on the second intermediate block (e.g., D1) and the input block (e.g., A5) to generate a third intermediate block (e.g., E5). In the example shown, the index of the input block operated by the third bitwise XOR operation matches the index of the third intermediate block produced by the third bitwise XOR operation (e.g., A5 is the input of the XOR operation that produces E5). Note that in some examples, E[x,y]=A[x,y]=A[x,y] XOR D[x].

[0073] The ρ step (rho step) 105 performs a bitwise rotation of some offset on most of the "E" values ​​generated in the θ step (theta step) 103. Note that E0 is not rotated. In some examples, the ρ step (rho step) 105 is defined by A[x,y]=ROT(A[x,y],r[x,y]), where r[x,y] is the rotation offset. In this definition, A[x,y] is "E".

[0074] The π step (pi step) 107 is another rotation step. In some examples, this step is defined by B[y,2x+3y]=ROT(A[x,y]).

[0075] Figure 4 An example is shown where the p-step (rho-step) 105 and the π-step (pi-step) 107 are performed together. This is defined as:

[0076]

[0077] In some examples, this is performed simply by rewiring without using gates. The rotation numbers in the figure apply directly to full-length Keccak1600 permutations. However, for variable lane sizes w, these numbers are taken after modulo division with respect to w. For example, the rotation amount of E1→B8 would be 36%16=4, where w=16 (Keccak400). In a flexible design that supports various values ​​of w, these rotation offsets are stored in memory elements and retrieved during execution of the rotation.

[0078] The chi step 109 includes nonlinear operations. In some examples, these operations perform affine mapping. In some examples, the chi step 109 is defined as:

[0079]

[0080] The iota step 111 can be calculated by the following equation:

[0081]

[0082] In the ι step 111, a w-bit variable called the round constant (RC) is XORed to the first w bits of the output of the χ step. The SHA-3 authors have provided the value of this variable for each round. In some examples, the following set of new Boolean equations instantly derive the RC value.

[0083] nr0=~r0; nr1=~r1; nr2=~r2; nr3=~r3; nr4=~r4;

[0084] RC0=(nr4&(nr3|(nr1&nr0)|(r2&nr1)))|(r4&((r3&r1)|(nr3&r0)));

[0085] RC1=nr1&nr0|(nr4&(((r1&r0)&(nr3|nr2))|(nr3&nr2&nr1)))|(r4&((r3&r2&nr1)|(nr

[0086] 3&r1&nr0)));

[0087] RC3=(nr1&nr0)|(nr4&((r2&r0)|(nr2&r1)))|(r4&nr3&r2&nr0);

[0088] RC7=(nr4&((nr1&nr0)|(nr3&r1)|(r3&nr2&(nr1|nr0))))|(r4&((r2&nr1)|(r3&nr2)|(n

[0089] r3&r1&r0)));

[0090] RC 15 =(nr4&((r3&((nr1&nr0)|r2))|(nr3&(r1|r0))))|(r4&((r3&nr2)|(r3^r1)));

[0091] RC 31 =(nr4&((nr2&nr1&nr0)|(nr3&r2&nr1&r0)|r3&((r2&r1)|(r1&r0))))|(r4&((nr3

[0092] &nr2&nr1)|(r1&(r3^r0))));

[0093] RC 63 =(nr4&((r3&(r0|r2))|(nr3&nr2)|(r2&nr1&nr0)))|(r4&((r3&(nr2|(nr1&nr0)))|(

[0094] nr3&r1&r0)|(nr2&r1&nr0)));

[0095] In some examples, r i (0≤i≤4) is the 5-bit output of the linear feedback shift register (LFSR) round counter. Figure 5 An example of a linear feedback shift register round counter is shown in FIG. As shown in the figure, the LFSR counter uses the primitive polynomial X 5 +X 2 +1 and an initial state of 11111 to represent the first round. The state of each clock represents the corresponding incremental round. Execution stops at round 24. Using an LFSR provides significant savings compared to the lookup table approach.

[0096] In some examples, the χ step (chi step) 109 and the ι step (iota step) 111 are combined. Figure 6 An example of a combined χ step (chi step) and ι step (iota step) is illustrated. The nonlinear function is implemented as shown in the NL block. The w-bit XOR array performs the ι step there. In summary, this combination uses 25w NOT gates, 25w dual-input AND gates, and 25w dual-input XOR gates.

[0097] The output of step iota 111 is provided as input to the next round (if it is determined at 113 that round 24 has not been completed) or is output as an output state variable of operation 115 (if it is determined at ISA13 that round 24 has been completed).

[0098] Figure 7An example of computing hardware that processes Keccak instructions is illustrated. As illustrated, a storage device 703 stores one or more Keccak instructions 701 to be executed and / or one or more other instructions 702 to be executed. It should be noted that Keccak is typically a step in SHA3 (e.g., the portion that absorbs the input into the state of each block). It should be noted that the internal state size of Keccak is 1600, and the block size can be 1152 bits (SHA3-224), 1088 bits (SHA3-256 or SHAKE256), 832 bits (SHA3-384), 576 bits (SHA3-512), 1344 bits (SHAKE128), etc.

[0099] The instruction from the storage device is received by the decoder circuit 705. For example, the decoder circuit 705 receives the instruction from the acquisition circuit (not shown). The instruction can be in any suitable format, such as the following reference Fig.24 The format described in the specification. In one example, the instruction includes fields for an opcode, one or more source identifiers, and one or more destination identifiers. In some examples, for Keccak instructions, the source and destination are registers, and in other examples, one or more are memory locations. It should be noted that the opcode indicates that a Keccak permutation is to be performed. In some examples, the opcode indicates the size of the register to be used. In some examples, an immediate or other operand indicates the size of the register to be used.

[0100] A more detailed example of at least one instruction format for an instruction will be described in detail later. Decoder circuit 705 decodes the instruction into one or more operations. In some examples, the decoding includes generating a plurality of micro-operations to be executed by an execution circuit (such as execution circuit 709). Decoder circuit 705 also decodes an instruction prefix.

[0101] In some examples, the register renaming, register allocation and / or scheduling circuitry 707 provides functionality for one or more of: 1) renaming logical operand values ​​to physical operand values ​​(e.g., a register alias table in some examples), 2) assigning status bits and flags to decoded instructions, and 3) scheduling decoded instructions for execution by execution circuitry from an instruction pool (e.g., using a reservation station in some examples).

[0102] Registers (register file) and / or memory 708 store data as operands for instructions to be operated on by execution circuitry 709. Example register types include packed data registers, general purpose registers (GPRs), and floating point registers.

[0103] The execution circuit 709 executes the decoded instructions. Example Detailed Description The execution circuit includes Figure 8 SHA3 ​​801 execution circuit shown and execution cluster 2160 shown in FIG. 21 (B) and the like. Execution of the decoded instructions causes the execution circuit to perform Keccak permutation. It should be noted that the execution unit is shown as being inside the core. In some examples, the SHA3 execution circuit is part of an accelerator.

[0104] In some examples, retirement / writeback circuitry 711 architecturally commits the result to a register or memory 708 and retires the instruction.

[0105] Figure 8 An example of an execution circuit for Keccak instruction processing is illustrated. In some examples, the execution circuit is a SHA3 execution circuit 801. In some examples, the SHA3 execution circuit 801 is part of a hardware accelerator. In some examples, the SHA3 execution circuit 801 is part of a general-purpose computing core (which utilizes Keccak instructions). The SHA3 execution circuit 801 may include non-Keccak circuits (other SHA3 circuits 815) to perform other SHA3 actions. Other execution data paths 809 outside the SHA3 execution circuit 801 may also be used to perform other SHA3 actions and / or other instructions. It should be noted that other SHA3 actions are typically called by the execution of other instructions.

[0106] The Keccak 1600 round data path 803 uses a combinational logic unit circuit to calculate the entire Keccak round on a 1600-bit Keccak state, which is provided in parallel or serially by multiple registers 807. In some examples, the output of the Keccak 1600 round data path 803 is stored in registers 807 before another round. In some examples, each round or each group of iterations uses a different input state. In some examples, in order to store the entire 1600-bit state inside the processor core, 25 64-bit GPRs are used (e.g., loaded using 25 conventional load operations). In some examples, wider registers are used, such as 128-bit, 256-bit, 512-bit and / or 1024-bit wide registers, which reduce read / write latency.

[0107] In some examples, the entire Keccak 1600 permutation is atomically computed using 24 iterations of the Keccak 1600 round data path 803. In some examples, more than 1 round (e.g., 2, 3, or 4 rounds) of sequential rounds using the Keccak 1600 round data path are performed without going to register 807 ( Figure 3 Examples of sequential Keccak1600 rounds are illustrated without storage to memory). These sequential rounds are atomically iterated 12 (for 2 sequential rounds), 8, 6, etc. times to compute all 24 rounds of Keccak1600 permutations.

[0108] Each Keccak1600 round uses a different round constant. In some examples, a round counter and control logic (eg, circuit) 805 within the SHA3 circuit 801 generates the round constant.

[0109] The number of Keccak rounds is also tracked by the round counter and control logic 805. The round counter and control logic 805 generates a corresponding register update signal in the exact number of cycles that the data path 803 needs to iterate to perform all 24 rounds.

[0110] In some examples, the round counter and control logic 805 are initialized by a start pulse generated as part of execution of a Keccak instruction.

[0111] After all 24 rounds are completed, the round counter and control logic 805 asserts a done signal, which alerts the processor's control logic 813 that a new Keccak state is ready inside the corresponding register.

[0112] In some examples, a single Keccak instruction is executed to perform all 24 rounds of Keccak1600 permutations. In some embodiments, the Keccak instruction includes one or more address fields for 1600-bit input and 1600-bit output. The address field can point to multiple registers, memory 811, or a combination thereof (e.g., reading from a register and writing to a memory). When memory 811 is indicated as a source, control logic 813 causes the input state from a specified memory location to be loaded into the specified register before generating a start indication. When memory 811 is indicated as a destination, control logic 813 causes the output state to be written from register 807 to memory 811.

[0113] In some examples, multiple Keccak instructions are executed to perform all 24 rounds of Keccak1600 permutation. In some embodiments, the Keccak instruction includes one or more address fields for 1600-bit input and 1600-bit output. The address field can point to multiple registers, memory 811, or a combination thereof (e.g., reading from a register and writing to a memory). When the memory 811 is indicated as a source, the control logic 813 causes the input state from the specified memory location to be loaded into the specified register before generating a start indication. When the memory 811 is indicated as a destination, the control logic 813 causes the output state to be written from the register 807 to the memory 811. In some examples, the opcode determines how many rounds to be executed. In some examples, the immediate number determines how many rounds to be executed.

[0114] In some examples, the loading and storing of input and output states occurs outside of the Keccak instructions. Thus, the software will execute a set of load instructions to bring the input states from the memory 811 to a set of registers, and then call the Keccak instructions.

[0115] After the Keccak instruction retires, the resulting state is further used. For example, it can be XORed with the next message block and message hashing can continue by calling another Keccak instruction. Or other aspects of SHA3 can be performed.

[0116] Fig. 9 An example of a Keccak1600 round data path is illustrated. Note that while two paths are shown when masked x is not used, only the top (905-909, 921, and 923) will be used and normal x is applied. In some examples, when masked x is not used, the input state is not masked. In some examples, when masked x is not used, the input state is masked.

[0117] Although this is shown as a combinational logic block (circuit), in some examples, one or more aspects of the data path are implemented in software or firmware. In some examples, the data path is a Keccak 1600 round data path 803. The mask register 903 stores a 1600-bit mask variable that is XORed with the 1600-bit input state to generate a masked state to be stored in the masked state register 901.

[0118] In general, the secret input state (1600-bit input state) is split into any number (n) of states, where n is an integer and n>=2. The result is obtained by combining all n states. The randomness required for the input of the split operation can be obtained from any n-1 final states of the previous operation. Values ​​of n>2 provide protection against higher-order attacks.

[0119] In some examples, the mask register is initialized by taking a random input (e.g., 128 bits or longer) and extending it by performing 24 rounds of Keccak1600 on the same Keccak1600 round data path 803. The initialization and subsequent masked Keccak1600 permutation can be performed by following the representation Fig.101006. The state transition diagram of the state machine shown in FIG. 1007 is used to execute. In the idle state 1001, both registers are reset to zero. In the initialized mask state 1003, the state input carries 128 bits or longer random bits filled in any 128 bit position in the 1600 bits. The engine then runs 24 rounds. Finally, the mask register will hold the random 1600 bit value and the Keccak1600 round data path 803 in the ready state 1005 to process Keccak1600 (in the processing state 1007) on any input state in the side channel protection mode. In some examples, the local round counter and control logic 805 execute the state machine.

[0120] In some examples, the state machine used to generate the initial secret state from the random seed can be customized in various ways. For example, the Keccak permutation can be run for a number of rounds other than 24.

[0121] In one embodiment, the entire 1600 bit masking state can be taken as a random input from an external source, which involves a large amount of random input from outside the Keccak 1600 round data path 803.

[0122] The masked state and mask are independently subjected to the Keccak linear mapping steps (θ, ρ, π) sequentially in the combinatorial logic block (e.g., the masked state passes through θ905, ρ907, and π909, and the mask passes through θ915, ρ917, and π919). Although shown as separate logic blocks, in some examples, the same logic block is used for the masked state and the mask (e.g., alternating at each step or alternating after all 3 steps).

[0123] After the linear mapping step is completed, the nonlinear operation (χ) of Keccak is performed. The nonlinear operation is masked so that the mask and the masked state do not reassemble the protected sensitive value. As described above, the normal χ is calculated according to the following formula:

[0124]

[0125] In masked χ921, two values ​​are generated - one for the masked state and one for the mask. Fig.11 Examples of normal χ and masked χ steps are illustrated. On the left is normal χ with a single bit updated. Note that “a”, “b”, and “c” in the illustration map to B[x, y], and B[x+2,y].

[0126] On the right is the masked x that updates a single bit. The subscript numbers indicate the source of "a", "b", and "c", where subscript 1 is the masked state and subscript 2 is the masked state (in other examples, the subscripts are given the opposite meaning). The "r" value can be a random value, a set value (e.g., always 1 or always 0), a bit from a LFSR counter (e.g., r0), etc.

[0127] One output of the masked χ 921 is subjected to iota 923 .

[0128] In some examples, the Keccak 1600 round data path 803 is synthesis time parameterizable, so that, for example, 1, 2, 3, or 4 back-to-back rounds can be completed in the masked combinational logic. Therefore, the Keccak 1600 round data path 803 is iterated 24, 12, 8, or 6 times, respectively. The intermediate results of each iteration are stored in the masked state register 901 and the mask register 903.

[0129] For different tradeoffs between security and implementation metrics (e.g., area, power, latency), the masked x step can be implemented in various ways. As described above, one tradeoff is how many parts the state is decomposed into. Although two states are discussed, there is no limit on how many parts can be used. Another tradeoff is how many rounds of masked x steps are used. For example, all rounds or a proper subset of rounds (e.g., applied to the first i rounds and / or the last j rounds of Keccak, where i and j are integers and i, j>=2). In some examples, the input states are processed sequentially, and in some examples, intermediate results are used. In some examples, the order of the input states and / or the addresses of the registers storing intermediate values ​​are randomized.

[0130] Fig.12 An example method of processing Keccak instructions executed by a processor is illustrated. For example, the SHA3 execution circuit 801, the processor core as shown in FIG. 21(B), the pipeline as described in detail below, etc. execute the method.

[0131] At 1201, an instance of a single Keccak instruction is obtained, having a field for an opcode, a field for at least one location of a source for an input 1600-bit state, and a field for at least one location of a destination for an output 1600-bit state, wherein the opcode is used to indicate that a Keccak round is to be performed. In some examples, the opcode is also used to indicate the number of Keccak rounds to be performed. In some examples, one or more fields (such as an immediate value) are used to indicate the number of Keccak rounds to be performed. In some examples, the instruction includes one or more fields indicating a masked position. In some examples, the opcode indicates the use of a masked x.

[0132] At 1203, the fetched instruction is decoded. For example, the fetched Keccak instruction is decoded by a decoder circuit such as decoder circuit 705 or decode circuit 2140 described in detail herein.

[0133] At 1205, when the decoded instruction is dispatched, data values ​​associated with the source operands of the decoded instruction are retrieved. For example, when one or more source operands are memory operands, data is retrieved from the indicated memory location.

[0134] At 1207, the decoded instruction is executed by execution circuitry (hardware), such as Figure 7 21(B) or the execution cluster 2160. For a Keccak instruction, execution will cause the execution circuit to generate an output 1600-bit state from a 1600-bit input state. In some examples, a Keccak round utilizes a masked 1600-bit input state and a mask 1600-bit state.

[0135] In some examples, at 1209 , the instruction is committed or retired.

[0136] Fig.13 An example of a method performed by a processor to execute Keccak instructions using masking is illustrated. In some examples, the method is performed on a dedicated SHA3 hardware accelerator. In some examples, a SHA3 instruction in a general-purpose computing core calls the method. In some examples, the method is performed by software executing SHA3 on a general-purpose core using existing instructions.

[0137] It should be noted that one or more instructions may be executed. At 1301, a first state is generated from an input state. In some examples, the generation is done by using a random second state from a previous operation.

[0138] At 1303, a linear operation (θ, ρ, π) is performed independently on the (updated) first state and the (updated) second 1600-bit state.

[0139] At 1305, the outputs of the linear operations (θ, ρ, π) are combined in a non-linear (χ) calculation to produce a first set of update values ​​and a second set of update values.

[0140] At 1307, an iota step is performed on the first set of updated values ​​to generate an updated first state. This completes one round.

[0141] At 1309, a determination is made as to whether the desired number of rounds has been completed. In some examples, the local round counter and control logic 805 makes this determination.

[0142] If yes, then the execution stops. If no, then at 1311 the updated first and second states are XORed and output.

[0143] In some examples, the above method is used as not to use Figure 8 or Fig. 9 The software method for a specific circuit is implemented.

[0144] Some examples utilize the instruction formats described herein. Some examples are implemented in one or more computer architectures, cores, accelerators, etc. Some examples are generated or are IP cores. Some examples utilize simulation and / or translation.

[0145] Example Architecture

[0146] The following describes in detail an example computer architecture. Other system designs and configurations known in the art for laptop, desktop and handheld personal computers (PCs), personal digital assistants, engineering workstations, servers, decomposed servers, network devices, network hubs, switches, routers, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. Generally, various systems or electronic devices that can incorporate processors and / or other execution logic disclosed herein are generally suitable.

[0147] Example System

[0148] Fig.14 An example computing system is illustrated. Multiprocessor system 1400 is an interface system and includes multiple processors or cores, including a first processor 1470 and a second processor 1480 coupled via an interface 1450 such as a point-to-point (PP) interconnect, structure and / or bus. In some examples, the first processor 1470 and the second processor 1480 are isomorphic. In some examples, the first processor 1470 and the second processor 1480 are heterogeneous. Although example system 1400 is shown as having two processors, the system can have three or more processors, or can be a single processor system. In some examples, the computing system is a system on chip (SoC).

[0149] Processors 1470 and 1480 are shown as including integrated memory controller (IMC) circuits 1472 and 1482, respectively. Processor 1470 also includes interface circuits 1476 and 1478; similarly, second processor 1480 includes interface circuits 1486 and 1488. Processors 1470, 1480 may exchange information via interface 1450 using interface circuits 1478, 1488. IMCs 1472 and 1482 couple processors 1470, 1480 to respective memories, namely memory 1432 and memory 1434, which may be portions of main memory locally attached to the respective processors.

[0150] Processors 1470, 1480 can each exchange information with a network interface (NW I / F) 1490 via separate interfaces 1452, 1454 using interface circuits 1476, 1494, 1486, 1498. Network interface 1490 (e.g., one or more of an interconnect, bus, and / or fabric, and in some examples a chipset) can optionally exchange information with a coprocessor 1438 via interface circuit 1492. In some examples, coprocessor 1438 is a special-purpose processor, such as, for example, a high-throughput processor, a network or communication processor, a compression engine, a graphics processor, a general-purpose graphics processing unit (GPGPU), a neural network processing unit (NPU), an embedded processor, etc.

[0151] A shared cache (not shown) may be included in either processor 1470, 1480 or external to both processors but connected to the processors via an interface such as a PP interconnect so that if the processors are placed in a low power mode, local cache information of either or both of the two processors may be stored in the shared cache.

[0152] The network interface 1490 may be coupled to the first interface 1416 via the interface circuit 1496. In some examples, the first interface 1416 may be an interface such as a peripheral component interconnect (PCI), a PCI Express interconnect, or another I / O interconnect. In some examples, the first interface 1416 is coupled to a power control unit (PCU) 1417, which may include circuits, software, and / or firmware that perform power management operations with respect to the processors 1470, 1480, and / or the coprocessor 1438. The PCU 1417 provides control information to a voltage regulator (not shown) so that the voltage regulator generates an appropriate regulated voltage. The PCU 1417 also provides control information that controls the generated operating voltage. In various examples, the PCU 1417 may include various power management logic units (circuits) that perform hardware-based power management. Such power management may be fully processor-controlled (e.g., through various processor hardware, and it may be triggered by workload and / or power, thermal, or other processor constraints) and / or power management may be performed in response to an external source (such as a platform or power management source or system software).

[0153] PCU 1417 is illustrated as existing as logic separate from processor 1470 and / or processor 1480. In other cases, PCU 1417 may execute on a given one or more of the cores (not shown) of processor 1470 or 1480. In some cases, PCU 1417 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is configured to execute its own dedicated power management code, sometimes referred to as P-code. In other examples, the power management operations to be performed by PCU 1417 may be implemented external to the processor, such as by a separate power management integrated circuit (PMIC) or another component external to the processor. In other examples, the power management operations to be performed by PCU 1417 may be implemented in BIOS or other system software.

[0154] Various I / O devices 1414 may be coupled to the first interface 1416 along with a bus bridge 1418 coupling the first interface 1416 to the second interface 1420. In some examples, one or more additional processors 1415 such as a coprocessor, a high throughput integrated many core (MIC) processor, a GPGPU, an accelerator (such as a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor are coupled to the first interface 1416. In some examples, the second interface 1420 may be a low pin count (LPC) interface. Various devices may be coupled to the second interface 1420, including, for example, a keyboard and / or mouse 1422, a communication device 1427, and a storage circuit 1428. The storage circuit 1428 may be one or more non-transitory machine-readable storage media as described below, such as a disk drive or other mass storage device, which may include instructions / codes and data 1430 and may implement the storage device 703 in some examples. Further, an audio I / O 1424 may be coupled to the second interface 1420. It should be noted that other architectures besides the point-to-point architecture described above are also possible. For example, instead of a point-to-point architecture, a system such as multiprocessor system 1400 may implement a multi-point interface or other such architecture.

[0155] Example core architectures, processors, and computer architectures.

[0156] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) general-purpose in-order cores intended for general-purpose computing; 2) high-performance general-purpose out-of-order cores intended for general-purpose computing; 3) dedicated cores primarily intended for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU that includes one or more general-purpose in-order cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor that includes one or more dedicated cores primarily intended for graphics and / or scientific (throughput) computing. Such different processors lead to different computer system architectures, which may include: 1) a coprocessor on a chip separate from the CPU; 2) a coprocessor on a separate die in the same package as the CPU; 3) a coprocessor on the same die as the CPU (in this case, such a coprocessor is sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or referred to as a dedicated core); and 4) a system on a chip (SoC), which may be included on the same die as the CPU (sometimes referred to as an application core or application processor), the above-mentioned coprocessor, and additional functions. An example core architecture is described next, followed by a description of example processor and computer architectures.

[0157] Fig.15 A block diagram of an example processor and / or SoC 1500 that may have one or more cores and an integrated memory controller is illustrated. The solid lined box illustrates a processor 1500 having a single core 1502(A), a system agent unit circuit 1510, and a set of one or more interface controller unit circuits 1516, while the optional addition of the dashed lined box illustrates an alternative processor 1500 having multiple cores 1502(A)-(N), a set of one or more integrated memory controller unit circuits 1514 and dedicated logic 1508 in the system agent unit circuit 1510, and a set of one or more interface controller unit circuits 1516. It should be noted that the processor 1500 may be one of the processors 1470 or 1480, or may be a processor 1470 or 1480. Fig.14 coprocessor 1438 or 1415.

[0158] Thus, different implementations of processor 1500 may include: 1) a CPU having: dedicated logic 1508, which is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown); and cores 1502(A)-(N), which are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of both); 2) a coprocessor having cores 1502(A)-(N), which are a large number of dedicated cores primarily intended for graphics and / or scientific (throughput); and 3) a coprocessor having cores 1502(A)-(N), which are a large number of general purpose in-order cores. Thus, processor 1500 may be a general purpose processor, a coprocessor, or a dedicated processor, such as, for example, a network or communications processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 1500 may be part of and / or may be implemented on one or more substrates using any of a variety of process technologies, such as, for example, complementary metal oxide semiconductor (CMOS), bipolar CMOS (BiCMOS), P-type metal oxide semiconductor (PMOS), or N-type metal oxide semiconductor (NMOS).

[0159] The memory hierarchy includes one or more levels of cache unit circuits 1504(A)-(N) within the cores 1502(A)-(N), a set of one or more shared cache unit circuits 1506, and external memory (not shown) coupled to the set of integrated memory controller unit circuits 1514. The set of one or more shared cache unit circuits 1506 may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache (such as a last level cache (LLC)), and / or combinations thereof. While in some examples, an interface network circuit 1512 (e.g., a ring interconnect) interfaces with dedicated logic 1508 (e.g., integrated graphics logic), the set of shared cache unit circuits 1506, and the system agent unit circuit 1510, alternative examples use any number of well-known techniques to interface with such units. In some examples, coherency is maintained between the shared cache unit circuits 1506 and one or more of the cores 1502(A)-(N). In some examples, interface controller unit circuit 1516 couples core 1502 to one or more other devices 1518, such as one or more I / O devices, storage devices, one or more communication devices (e.g., wireless networking, wired networking, etc.), and the like.

[0160] In some examples, one or more of the cores 1502(A)-(N) are capable of multithreading. System agent unit circuitry 1510 includes those components that coordinate and operate the cores 1502(A)-(N). System agent unit circuitry 1510 may include, for example, power control unit (PCU) circuitry and / or display unit circuitry (not shown). The PCU may be or may include logic and components required to regulate the power state of the cores 1502(A)-(N) and / or the dedicated logic 1508 (e.g., integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

[0161] The cores 1502(A)-(N) may be homogeneous in terms of instruction set architecture (ISA). Alternatively, the cores 1502(A)-(N) may be heterogeneous in terms of ISA; that is, a subset of the cores 1502(A)-(N) may be capable of executing an ISA, while other cores may be capable of executing only a subset of that ISA or another ISA.

[0162] Fig.161 is a block diagram illustrating a computing system 1600 configured to implement one or more aspects of the examples described herein. The computing system 1600 includes a processing subsystem 1601 having one or more processors 1602 and a system memory 1604 communicating via an interconnect path that may include a memory hub 1605. The memory hub 1605 may be a separate component within a chipset component, or may be integrated within the one or more processors 1602. The memory hub 1605 is coupled to an I / O subsystem 1611 via a communication link 1606. The I / O subsystem 1611 includes an I / O hub 1607, which may enable the computing system 1600 to receive input from one or more input devices 1608. In addition, the I / O hub 1607 may enable a display controller that may be included in the one or more processors 1602 to provide output to one or more display devices 1610A. In some examples, the one or more display devices 1610A coupled to the I / O hub 1607 may include local, internal, or embedded display devices.

[0163] The processing subsystem 1601 includes, for example, one or more parallel processors 1612 coupled to the memory hub 1605 via a bus or other communication link 1613. The communication link 1613 can be one of any number of standard-based communication link technologies or protocols, such as but not limited to PCI Express, or can be a vendor-specific communication interface or communication structure. The one or more parallel processors 1612 can form a computationally focused parallel or vector processing system, which can include a large number of processing cores and / or processing clusters, such as an integrated many-core (MIC) processor. For example, the one or more parallel processors 1612 form a graphics processing subsystem that can output pixels to one of the one or more display devices 1610A coupled via the I / O hub 1607. The one or more parallel processors 1612 can also include a display controller and a display interface (not shown) to enable direct connection to one or more display devices 1610B.

[0164] Within the I / O subsystem 1611, a system storage unit 1614 may be connected to the I / O hub 1607 to provide a storage mechanism for the computing system 1600. An I / O switch 1616 may be used to provide an interface mechanism that enables connection between the I / O hub 1607 and other components such as a network adapter 1618 and / or a wireless network adapter 1619 that may be integrated into the platform and various other devices that may be added via one or more additional devices 1620. Additional devices 1620 may also include, for example, one or more external graphics processor devices, graphics cards, and / or computing accelerators. The network adapter 1618 may be an Ethernet adapter or another wired network adapter. The wireless network adapter 1619 may include one or more of Wi-Fi, Bluetooth, near field communication (NFC), or other network devices including one or more wireless radios.

[0165] Computing system 1600 may include other components not explicitly shown, including USB or other port connections, optical storage drives, video capture devices, etc., which may also be connected to I / O hub 1607. Fig.16 The communication paths of the various components in the system may be implemented using any suitable protocol, such as a PCI (Peripheral Component Interconnect) based protocol (e.g., PCI Express) or any other bus or point-to-point communication interface and / or protocol, such as NVLink high-speed interconnect, Compute Express Link™ (CXL TM ) )(e.g., CXL.mem), Infinity Fabric (IF), Ethernet (IEEE 802.3), Remote Direct Memory Access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connection (QUIC), RDMA over Converged Ethernet (RoCE), Intel Quick Path Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel System on Chip Fabric (IOSF), Omnichannel, HyperTransport, Advanced Microcontroller Bus Architecture (AMBA) Interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, and variations thereof, or a wired or wireless interconnect protocol known in the art. In some examples, data may be copied or stored to a virtualized storage node using a protocol such as Non-Volatile Memory Express (NVMe) (NVMe-oF) or NVMe over Fabric.

[0166] One or more parallel processors 1612 may be incorporated with circuits optimized for graphics and video processing, including, for example, video output circuits, and constitute a graphics processing unit (GPU). Alternatively or additionally, one or more parallel processors 1612 may be incorporated with circuits optimized for general processing while retaining the underlying computing architecture, as described in more detail herein. The components of the computing system 1600 may be integrated with one or more other system elements on a single integrated circuit. For example, one or more parallel processors 1612, a memory hub 1605, a processor 1602, and an I / O hub 1607 may be integrated into a system on chip (SoC) integrated circuit. Alternatively, the components of the computing system 1600 may be integrated into a single package to form a system in package (SIP) configuration. In some examples, at least a portion of the components of the computing system 1600 may be integrated into a multi-chip module (MCM), which may be interconnected with other multi-chip modules into a modular computing system.

[0167] It should be understood that the computing system 1600 shown herein is illustrative, and variations and modifications are possible. The connection topology, including the number and arrangement of bridges, the number of processors 1602, and the number of parallel processors 1612, can be modified as desired. For example, the system memory 1604 can be directly connected to the processor 1602 instead of through a bridge, and other devices communicate with the system memory 1604 via the memory hub 1605 and the processor 1602. In other alternative topologies, the parallel processors 1612 are connected to the I / O hub 1607 or directly connected to one of the one or more processors 1602, rather than being connected to the memory hub 1605. In other examples, the I / O hub 1607 and the memory hub 1605 can be integrated into a single chip. It is also possible to attach two or more groups of processors 1602 via multiple sockets, which can be coupled to two or more instances of the parallel processor 1612.

[0168] Some of the specific components shown herein are optional and may not be included in all embodiments of computing system 1600. For example, any number of add-in cards or peripherals may be supported, or some components may be removed. In addition, some architectures may be specific to the Fig.16 Different terminology is used for similar components as illustrated. For example, in some architectures, the memory hub 1605 may be referred to as a Northbridge, while the I / O hub 1607 may be referred to as a Southbridge.

[0169] Fig.17AAn example of a parallel processor 1700 is illustrated. Parallel processor 1700 may be a GPU, a GPGPU, etc., as described herein. Various components of parallel processor 1700 may be implemented using one or more integrated circuit devices, such as a programmable processor, an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA). The illustrated parallel processor 1700 may be Fig.16 One or more of the parallel processors 1612 are shown.

[0170] Parallel processor 1700 includes parallel processing unit 1702. Parallel processing unit includes I / O unit 1704, which enables communication with other devices including other instances of parallel processing unit 1702. I / O unit 1704 can be directly connected to other devices. For example, I / O unit 1704 is connected to other devices by using a hub or switch interface (such as memory hub 1605). The connection between memory hub 1605 and I / O unit 1704 forms communication link 1613. Within parallel processing unit 1702, I / O unit 1704 is connected to host interface 1706 and memory crossbar 1716, wherein host interface 1706 receives commands dedicated to performing processing operations, and memory crossbar 1716 receives commands dedicated to performing memory operations.

[0171] When the host interface 1706 receives the command buffer via the I / O unit 1704, the host interface 1706 may direct the work operations to execute the commands to the front end 1708. In some examples, the front end 1708 is coupled with a scheduler 1710, which is configured to distribute commands or other work items to the processing cluster array 1712. The scheduler 1710 ensures that the processing cluster array 1712 is properly configured and is in a valid state before the task is distributed to the processing cluster of the processing cluster array 1712. The scheduler 1710 may be implemented via firmware logic executed on a microcontroller. The microcontroller-implemented scheduler 1710 may be configured to perform complex scheduling and work distribution operations at coarse and fine granularity, thereby achieving fast preemption and context switching of threads executed on the processing cluster array 1712. Preferably, the host software may prove the workload for scheduling on the processing cluster array 1712 via one of a plurality of graphics processing doorbells. In other examples, polling for new workloads or interrupts may be used to identify or indicate the availability of work to be executed. The scheduler 1710 logic within the scheduler microcontroller can then automatically distribute the workload across the array of processing clusters 1712 .

[0172] Processing cluster array 1712 may include up to "N" processing clusters (e.g., cluster 1714A, cluster 1714B to cluster 1714N). Each cluster 1714A-1714N of processing cluster array 1712 may execute a large number of concurrent threads. Scheduler 1710 may allocate work to clusters 1714A-1714N of processing cluster array 1712 using various scheduling and / or work allocation algorithms, which may vary depending on the workload generated by various types of programs or calculations. Scheduling may be handled dynamically by scheduler 1710, or may be partially assisted by compiler logic during compilation of program logic configured for execution by processing cluster array 1712. Optionally, different clusters 1714A-1714N of processing cluster array 1712 may be allocated to process different types of programs or to perform different types of calculations.

[0173] Processing cluster array 1712 may be configured to perform various types of parallel processing operations. For example, processing cluster array 1712 is configured to perform general-purpose parallel computing operations. For example, processing cluster array 1712 may include logic to perform processing tasks including filtering of video and / or audio data, performing modeling operations (including physics operations), and performing data transformations.

[0174] Processing cluster array 1712 is configured to perform parallel graphics processing operations. In such examples where parallel processor 1700 is configured to perform graphics processing operations, processing cluster array 1712 may include additional logic to support the execution of such graphics processing operations, including but not limited to texture sampling logic to perform texture operations, and tessellation logic and other vertex processing logic. In addition, processing cluster array 1712 may be configured to execute graphics processing related shader programs, such as but not limited to vertex shaders, tessellation shaders, geometry shaders, and pixel shaders. Parallel processing unit 1702 may transfer data from system memory via I / O unit 1704 for processing. During processing, the transferred data may be stored to on-chip memory (e.g., parallel processor memory 1722) during processing and then written back to system memory.

[0175] In examples where parallel processing unit 1702 is used to perform graphics processing, scheduler 1710 may be configured to divide the processing workload into tasks of approximately equal size to better implement the allocation of graphics processing operations to multiple clusters 1714A-1714N of processing cluster array 1712. In some of these examples, portions of processing cluster array 1712 may be configured to perform different types of processing. For example, a first portion may be configured to perform vertex shading and topology generation, a second portion may be configured to perform tessellation and geometry shading, and a third portion may be configured to perform pixel shading or other screen space operations to produce a rendered image for display. Intermediate data generated by one or more clusters 1714A-1714N may be stored in a buffer to allow the intermediate data to be transferred between clusters 1714A-1714N for further processing.

[0176] During operation, processing cluster array 1712 may receive processing tasks to be performed via scheduler 1710, which receives commands defining processing tasks from front end 1708. For graphics processing operations, a processing task may include an index of data to be processed (e.g., surface (tile) data, primitive data, vertex data, and / or pixel data), and state parameters and commands defining how the data is to be processed (e.g., what program to execute). Scheduler 1710 may be configured to obtain an index corresponding to a task, or may receive an index from front end 1708. Front end 1708 may be configured to ensure that processing cluster array 1712 is configured to a valid state before initiating a workload specified by an incoming command buffer (e.g., a batch buffer, a push buffer, etc.).

[0177] Each of the one or more instances of the parallel processing unit 1702 may be coupled to a parallel processor memory 1722. The parallel processor memory 1722 may be accessed via a memory crossbar switch 1716, which may receive memory requests from the processing cluster array 1712 and the I / O unit 1704. The memory crossbar switch 1716 may access the parallel processor memory 1722 via a memory interface 1718. The memory interface 1718 may include a plurality of partition units (e.g., partition unit 1720A, partition unit 1720B, through partition unit 1720N), which may each be coupled to a portion (e.g., memory cells) of the parallel processor memory 1722. The number of partition units 1720A-1720N may be configured to be equal to the number of memory cells, such that a first partition unit 1720A has a corresponding first memory cell 1724A, a second partition unit 1720B has a corresponding second memory cell 1724B, and an Nth partition unit 1720N has a corresponding Nth memory cell 1724N. In other examples, the number of partition units 1720A-1720N may not be equal to the number of memory devices.

[0178] Memory units 1724A-1724N may include various types of memory devices, including dynamic random access memory (DRAM) or graphics random access memory, such as synchronous graphics random access memory (SGRAM), including graphics double data rate (GDDR) memory. Optionally, memory units 1724A-1724N may also include 3D stacked memory, including but not limited to high bandwidth memory (HBM). Those skilled in the art will appreciate that the specific implementation of memory units 1724A-1724N may vary and may be selected from one of a variety of conventional designs. Rendering targets such as frame buffers or texture maps may be stored across memory units 1724A-1724N, allowing partition units 1720A-1720N to write portions of various rendering targets in parallel to efficiently use the available bandwidth of parallel processor memory 1722. In some examples, local instances of parallel processor memory 1722 may be excluded to support a unified memory design that uses system memory in conjunction with local cache memory.

[0179] Optionally, any of the clusters 1714A-1714N of the processing cluster array 1712 has the ability to process data to be written to any of the memory units 1724A-1724N within the parallel processor memory 1722. The memory crossbar 1716 can be configured to transmit the output of each cluster 1714A-1714N to any partition unit 1720A-1720N or to another cluster 1714A-1714N, which can perform additional processing operations on the output. Each cluster 1714A-1714N can communicate with the memory interface 1718 through the memory crossbar 1716 to read from or write to various external memory devices. In one of the examples having a memory crossbar switch 1716, the memory crossbar switch 1716 has connections to a memory interface 1718 that communicates with the I / O unit 1704 and to a local instance of parallel processor memory 1722, thereby enabling processing units within different processing clusters 1714A-1714N to communicate with system memory or other memory that is not local to the parallel processing unit 1702. In general, the memory crossbar switch 1716 may be able to separate traffic flows between the clusters 1714A-1714N and the partition units 1720A-1720N, for example, using virtual channels.

[0180] Although a single instance of PPU 1702 is illustrated within PPU 1700, any number of instances of PPU 1702 may be included. For example, multiple instances of PPU 1702 may be provided on a single add-in card, or multiple add-in cards may be interconnected. For example, PPU 1702 may be a processor such as a processor 1700. Fig.16 The additional device 1620 of the additional device 1620 may be a graphics card such as an independent graphics card, which includes one or more GPUs, one or more memory devices, and a device-to-device or network or structure interface. Different instances of the parallel processing unit 1702 may be configured to interoperate, even if different instances have different numbers of processing cores, different amounts of local parallel processor memory and / or other configuration differences. Optionally, some instances of the parallel processing unit 1702 may include a floating point unit with higher precision relative to other instances. Systems incorporating one or more instances of the parallel processing unit 1702 or parallel processor 1700 may be implemented in various configurations and form factors, including but not limited to desktop, laptop or handheld personal computers, servers, workstations, game consoles and / or embedded systems. The coordinator may use one or more of the following to form a composite node for workload execution: decomposed processor resources, cache resources, memory resources, storage resources and networking resources.

[0181] In some examples, the parallel processing unit 1702 may be divided into multiple instances. The multiple instances may be configured to execute workloads associated with different clients in an isolated manner, thereby enabling a predetermined quality of service to be provided to each client. For example, each cluster 1714A-1714N may be divided and isolated from other clusters, thereby allowing the processing cluster array 1712 to be divided into multiple computing partitions or instances. In this configuration, the workloads executed on the isolated partitions are protected from the impact of failures or errors associated with different workloads executed on different partitions. The partition units 1720A-1720N may be configured to implement dedicated and / or isolated paths to memory for the clusters 1714A-1714N associated with the corresponding computing partitions. This data path isolation enables the computing resources within the partition to communicate with one or more allocated memory units 1724A-1724N without interference from the activities of other partitions.

[0182] Fig. 17B is a block diagram of the partition unit 1720. The partition unit 1720 may be Fig.17A1720N. As shown, partition unit 1720 includes L2 cache 1721, frame buffer interface 1725, and ROP 1726 (raster operation unit). L2 cache 1721 is a read / write cache that is configured to perform load and store operations received from memory crossbar switch 1716 and ROP 1726. Read misses and urgent write-back requests are output by L2 cache 1721 to frame buffer interface 1725 for processing. Updates can also be sent to the frame buffer via frame buffer interface 1725 for processing. In some examples, frame buffer interface 1725 is connected to a memory unit (such as ROP 1726) in the parallel processor memory. Fig.17A Partition unit 1720 may additionally or alternatively interface with a memory unit in the parallel processor memory via a memory controller (not shown).

[0183] In graphics applications, ROP 1726 is a processing unit that performs raster operations such as stencils, z-tests, blending, etc. ROP 1726 then outputs processed graphics data stored in graphics memory. In some examples, ROP 1726 includes or is coupled to CODEC 1727, which includes compression logic that compresses depth or color data written to memory or L2 cache 1721 and decompresses depth or color data read from memory or L2 cache 1721. The compression logic can be lossless compression logic that utilizes one or more of a variety of compression algorithms. The type of compression performed by CODEC 1727 may vary based on the statistical characteristics of the data to be compressed. For example, in some examples, incremental color compression is performed on depth and color data on a per-tile basis. In some examples, CODEC 1727 includes compression and decompression logic that can compress and decompress computational data associated with machine learning operations. CODEC 1727 can, for example, compress sparse matrix data for sparse machine learning operations. CODEC 1727 may also compress sparse matrix data encoded in a sparse matrix format (e.g., coordinate list encoding (COO), compressed sparse row (CSR), compressed sparse column (CSC), etc.) to generate compressed and encoded sparse matrix data. The compressed and encoded sparse matrix data may be decompressed and / or decoded prior to processing by the processing element, or the processing element may be configured to consume compressed, encoded, or compressed and encoded data for processing.

[0184] ROP 1726 may be included in each processing cluster (e.g., Fig.17AThe processed graphics data may be displayed on a display device (e.g., a display device such as a display unit 1720). Fig.16 1610A-1610B), is routed for further processing by the processor 1602, or is routed for processing by the processor 1602. Fig.17A The processing is further processed by one of the processing entities within parallel processor 1700.

[0185] Fig. 17C is a block diagram of a processing cluster 1714 within a parallel processing unit. For example, a processing cluster is Fig.17A An instance of one of the processing clusters 1714A-1714N. Processing cluster 1714 can be configured to execute many threads in parallel, wherein the term "thread" refers to an instance of a specific program executed on a specific input data set. Optionally, single instruction multiple data (SIMD) instruction issuance technology can be used to support the parallel execution of a large number of threads without providing multiple independent instruction units. Alternatively, single instruction multiple thread (SIMT) technology can be used to support the parallel execution of a large number of generally synchronized threads, using a common instruction unit configured to issue instructions to a group of processing engines within each processing cluster. Unlike the SIMD execution mode (where all processing engines typically execute the same instructions), SIMT execution allows different threads to more easily follow the divergent execution path through a given thread program. Those skilled in the art will understand that the SIMD processing mode represents a functional subset of the SIMT processing mode.

[0186] The operation of the processing cluster 1714 can be controlled via a pipeline manager 1732 that distributes processing tasks to SIMT parallel processors. The pipeline manager 1732 Fig.17A The scheduler 1710 receives instructions and manages the execution of these instructions via the graphics multiprocessor 1734 and / or the texture unit 1736. The illustrated graphics multiprocessor 1734 is an exemplary instance of a SIMT parallel processor. However, various types of SIMT parallel processors of different architectures may be included in the processing cluster 1714. One or more instances of the graphics multiprocessor 1734 may be included in the processing cluster 1714. The graphics multiprocessor 1734 may process data, and the data crossbar 1740 may be used to distribute the processed data to one of a plurality of possible destinations, including other shader units. The pipeline manager 1732 may facilitate the distribution of processed data by specifying the destination of the processed data to be distributed via the data crossbar 1740.

[0187] Each graphics multiprocessor 1734 within a processing cluster 1714 may include a set of identical function execution logic (e.g., arithmetic logic units, load-store units, etc.). The function execution logic may be configured in a pipelined manner, where a new instruction may be issued before a previous instruction is completed. The function execution logic supports a variety of operations, including integer and floating point arithmetic, comparison operations, Boolean operations, bit shifts, and calculation of various algebraic functions. The same functional unit hardware may be utilized to perform different operations, and any combination of functional units may be present.

[0188] The instructions transmitted to the processing cluster 1714 constitute threads. A group of threads executed across the group of parallel processing engines is a thread group. The thread group executes the same program on different input data. Individual threads within a thread group can be assigned to different processing engines within the graphics multiprocessor 1734. A thread group may include fewer threads than the number of processing engines within the graphics multiprocessor 1734. When a thread group includes fewer threads than the number of processing engines, one or more of the processing engines may be idle during the cycle of processing the thread group. A thread group may also include more threads than the number of processing engines within the graphics multiprocessor 1734. When a thread group includes more threads than the number of processing engines within the graphics multiprocessor 1734, processing may be performed in consecutive clock cycles. Optionally, multiple thread groups may be executed concurrently on the graphics multiprocessor 1734.

[0189] Graphics multiprocessor 1734 may include an internal cache memory that performs load and store operations. Alternatively, graphics multiprocessor 1734 may abandon the internal cache and use a cache memory (e.g., level 1 (L1) cache 1748) within processing cluster 1714. Each graphics multiprocessor 1734 also has access to a partition unit (e.g., L1 cache 1748) that is shared among all processing clusters 1714 and can be used to transfer data between threads. Fig.17A 1720A-1720N). Graphics multiprocessor 1734 may also access off-chip global memory, which may include one or more of local PPU memory and / or system memory. Any memory external to PPU 1702 may be used as global memory. Embodiments where processing cluster 1714 includes multiple instances of graphics multiprocessor 1734 may share common instructions and data that may be stored in L1 cache 1748.

[0190] Each processing cluster 1714 may include an MMU 1745 (memory management unit) configured to map virtual addresses to physical addresses. In other examples, one or more instances of MMU 1745 may reside in Fig.17A1718. The MMU 1745 includes a set of page table entries (PTEs) for mapping virtual addresses to physical addresses of tiles and optionally cache line indexes. The MMU 1745 may include an address translation lookaside buffer (TLB) or cache that may reside within the graphics multiprocessor 1734 or L1 cache 1748 of the processing cluster 1714. Physical addresses are processed to assign surface data access locality, allowing efficient request interleaving between partition units. The cache line index can be used to determine whether a request for a cache line is a hit or a miss.

[0191] In graphics and compute applications, processing clusters 1714 may be configured such that each graphics multiprocessor 1734 is coupled to a texture unit 1736 for performing texture mapping operations, such as determining texture sample locations, reading texture data, and filtering texture data. Texture data is read from an internal texture L1 cache (not shown) or in some examples from an L1 cache within a graphics multiprocessor 1734, and retrieved from an L2 cache, local parallel processor memory, or system memory when needed. Each graphics multiprocessor 1734 outputs a processed task to a data crossbar 1740 to provide the processed task to another processing cluster 1714 for further processing, or stores the processed task in an L2 cache, local parallel processor memory, or system memory via a memory crossbar 1716. A preROP 1742 (pre-raster operations unit) is configured to receive data from a graphics multiprocessor 1734, direct the data to a ROP unit, which may communicate with a partition unit (e.g., Fig.17A The preROP 1742 unit may perform color blending optimizations, organize pixel color data, and perform address translation.

[0192] It should be understood that the core architecture described herein is illustrative and that variations and modifications are possible. Any number of processing units may be included within a processing cluster 1714, such as a graphics multiprocessor 1734, a texture unit 1736, a preROP 1742, etc. Further, while only one processing cluster 1714 is shown, a parallel processing unit as described herein may include any number of instances of a processing cluster 1714. Optionally, each processing cluster 1714 may be configured to operate independently of other processing clusters 1714 using separate and distinct processing units, L1 caches, L2 caches, etc.

[0193] Fig.17DAn example of a graphics multiprocessor 1734 is shown, where the graphics multiprocessor 1734 is coupled to a pipeline manager 1732 of a processing cluster 1714. The graphics multiprocessor 1734 has an execution pipeline that includes, but is not limited to, an instruction cache 1752, an instruction unit 1754, an address mapping unit 1756, a register file 1758, one or more general purpose graphics processing unit (GPGPU) cores 1762, and one or more load / store units 1766. The GPGPU cores 1762 and the load / store units 1766 are coupled to a cache memory 1772 and a shared memory 1770 via a memory and cache interconnect 1768. The graphics multiprocessor 1734 may additionally include a tensor and / or ray tracing core 1763 that includes hardware logic to accelerate matrix and / or ray tracing operations.

[0194] The instruction cache 1752 may receive an instruction stream to be executed from the pipeline manager 1732. The instructions are cached in the instruction cache 1752 and dispatched for execution by the instruction unit 1754. The instruction unit 1754 may dispatch instructions as thread groups (e.g., warps), where the threads of the thread groups are assigned to different execution units within the GPGPU core 1762. Instructions may access any of the local, shared, or global address spaces by specifying an address within the unified address space. The address mapping unit 1756 may be used to translate addresses in the unified address space into different memory addresses accessible by the load / store unit 1766.

[0195] The register file 1758 provides a set of registers for the functional units of the graphics multiprocessor 1734. The register file 1758 provides temporary storage for operands of the data paths of the functional units (e.g., GPGPU core 1762, load / store unit 1766) connected to the graphics multiprocessor 1734. The register file 1758 may be divided between the various functional units so that each functional unit is allocated a dedicated portion of the register file 1758. For example, the register file 1758 may be divided between different warps executed by the graphics multiprocessor 1734.

[0196] The GPGPU cores 1762 may each include a floating point unit (FPU) and / or an integer arithmetic logic unit (ALU) for executing instructions of the graphics multiprocessor 1734. In some embodiments, the GPGPU core 1762 may include hardware logic that may otherwise reside within the tensor and / or ray tracing core 1763. The GPGPU cores 1762 may be architecturally similar or architecturally different. For example, in some examples, the first portion of the GPGPU core 1762 includes a single-precision FPU and an integer ALU, while the second portion of the GPGPU core includes a double-precision FPU. Optionally, the FPU may implement the IEEE 754-2008 standard for floating-point operations, or enable variable-precision floating-point operations. The graphics multiprocessor 1734 may additionally include one or more fixed-function or special-function units that perform specific functions such as copying rectangles or pixel blending operations. One or more GPGPU cores may also include fixed or special-function logic.

[0197] GPGPU core 1762 may include SIMD logic capable of executing a single instruction to multiple data sets. Optionally, GPGPU core 1762 may physically execute SIMD4, SIMD8, and SIMD16 instructions, and logically execute SIMD1, SIMD2, and SIMD32 instructions. SIMD instructions for GPGPU cores may be generated by a shader compiler at compile time, or may be automatically generated when executing a program written and compiled for a single program multiple data (SPMD) or SIMT architecture. Multiple threads of a program configured for a SIMT execution model may be executed via a single SIMD instruction. For example, in some examples, eight SIMT threads performing the same or similar operation may be executed in parallel via a single SIMD8 logic unit.

[0198] The memory and cache interconnect 1768 is an interconnect network that connects the various functional units of the graphics multiprocessor 1734 to the register file 1758 and the shared memory 1770. For example, the memory and cache interconnect 1768 is a crossbar interconnect that allows the load / store unit 1766 to perform load and store operations between the shared memory 1770 and the register file 1758. The register file 1758 can operate at the same frequency as the GPGPU core 1762, so that data transfers between the GPGPU core 1762 and the register file 1758 are very low latency. The shared memory 1770 can be used to implement communication between threads executing on the functional units within the graphics multiprocessor 1734. The cache memory 1772 can be used, for example, as a data cache that caches texture data transferred between the functional units and the texture unit 1736. The shared memory 1770 can also be used as a program management cache. Shared memory 1770 and cache memory 1772 may be coupled to data crossbar switch 1740 to enable communication with other components of the processing cluster. In addition to automatically cached data stored in cache memory 1772, threads executing on GPGPU core 1762 may also programmatically store data in shared memory.

[0199] 18A to 18C Additional graphics multiprocessors according to examples are illustrated. FIG. 18A to FIG. 18B Graphics multiprocessors 1825 and 1850 are illustrated, which are Fig. 17C The graphics multiprocessor 1734 of FIG. 1825 and FIG. 1850 are related and can be used to replace one of them. Therefore, the disclosure of any feature in this article in combination with the graphics multiprocessor 1734 also discloses the corresponding combination with the graphics multiprocessors 1825 and 1850, but is not limited to this. Fig.18C A graphics processing unit (GPU) 1880 is illustrated, which includes multiple groups of dedicated graphics processing resources arranged into multi-core groups 1865A-1865N, which correspond to graphics multiprocessors 1825, 1850. The illustrated graphics multiprocessors 1825, 1850 and multi-core groups 1865A-1865N may be streaming multiprocessors (SMs) capable of executing a large number of execution threads simultaneously.

[0200] Fig.18A The graphics multiprocessor 1825 includes relative Fig.17DThe graphics multiprocessor 1825 may include multiple additional instances of execution resource units of the graphics multiprocessor 1734. For example, the graphics multiprocessor 1825 may include multiple instances of instruction units 1832A-1832B, register files 1834A-1834B, and texture units 1844A-1844B. The graphics multiprocessor 1825 also includes multiple groups of graphics or computational execution units (e.g., GPGPU cores 1836A-1836B, tensor cores 1837A-1837B, ray tracing cores 1838A-1838B) and multiple groups of load / store units 1840A-1840B. The execution resource units have a common instruction cache 1830, a texture and / or data cache memory 1842, and a shared memory 1846.

[0201] The various components may communicate via an interconnect structure 1827. The interconnect structure 1827 may include one or more crossbar switches that enable communication between the various components of the graphics multiprocessor 1825. The interconnect structure 1827 may be a separate high-speed network fabric layer on which the various components of the graphics multiprocessor 1825 are stacked. The components of the graphics multiprocessor 1825 communicate with remote components via the interconnect structure 1827. For example, the cores 1836A-1836B, 1837A-1837B, and 1838A-1838B may each communicate with the shared memory 1846 via the interconnect structure 1827. The interconnect structure 1827 may arbitrate communications within the graphics multiprocessor 1825 to ensure fair bandwidth allocation between components.

[0202] Fig.18B The graphics multiprocessor 1850 includes multiple groups of execution resources 1856A-1856D, wherein each group of execution resources includes multiple instruction units, register files, GPGPU cores, and load storage units, such as Fig.17D and Fig.18A 1856A-1856D may coordinate with texture units 1860A-1860D to perform texture operations while sharing instruction cache 1854 and shared memory 1853. For example, execution resources 1856A-1856D may share instruction cache 1854 and shared memory 1853, as well as multiple instances of texture and / or data caches 1858A-1858B. The various components may be communicated via a communication protocol similar to Fig.18A The interconnect structure 1827 communicates with the interconnect structure 1852.

[0203] Those skilled in the art should understand that Figure 1 , 17A to 17D and FIG. 18A to FIG. 18BThe architecture described in is illustrative and not limiting of the scope of the examples. Thus, without departing from the scope of the examples described herein, the techniques described herein may be implemented on any appropriately configured processing unit, including but not limited to one or more mobile application processors, one or more desktop or server central processing units (CPUs) including multi-core CPUs, such as Fig.17A One or more parallel processing units of parallel processing unit 1702, and one or more graphics processors or special processing units.

[0204] A parallel processor or GPGPU as described herein can be communicatively coupled to a host / processor core to accelerate graphics operations, machine learning operations, pattern analysis operations, and various general-purpose GPU (GPGPU) functions. The GPU can be communicatively coupled to the host processor / core via a bus or other interconnect (e.g., a high-speed interconnect such as PCIe, NVLink, or other known protocols, standardized protocols, or proprietary protocols). In other examples, the GPU can be integrated on the same package or chip as the core and communicatively coupled to the core via an internal processor bus / interconnect (i.e., inside the package or chip). Regardless of the manner in which the GPU is connected, the processor core can assign work to the GPU in the form of a sequence of commands / instructions contained in a work descriptor. The GPU then uses dedicated circuits / logic to efficiently process these commands / instructions.

[0205] Fig.18C A graphics processing unit (GPU) 1880 is illustrated, which includes dedicated multiple groups of graphics processing resources arranged into multi-core groups 1865A-1865N. Although only details of a single multi-core group 1865A are provided, it should be understood that other multi-core groups 1865B-1865N can be equipped with the same or similar groups of graphics processing resources. The details described about multi-core groups 1865A-1865N can also be applied to any graphics multiprocessor 1734, 1825, 1850 described herein.

[0206] As shown, multi-core group 1865A may include a group of graphics cores 1870, a group of tensor cores 1871, and a group of ray tracing cores 1872. Scheduler / dispatcher 1868 schedules and dispatches graphics threads for execution on the respective cores 1870, 1871, 1872. A group of register files 1869 stores operand values ​​used by cores 1870, 1871, 1872 when executing graphics threads. These register files may include, for example, integer registers for storing integer values, floating point registers for storing floating point values, vector registers for storing packed data elements (integer and / or floating point data elements), and tile registers for storing tensor / matrix values. Tile registers may be implemented as a combination of multiple groups of vector registers.

[0207] One or more combined level 1 (L1) caches and shared memory units 1873 store graphics data locally within each multi-core group 1865A, such as texture data, vertex data, pixel data, light data, bounding box data, etc. One or more texture units 1874 can also be used to perform texture operations, such as texture mapping and sampling. A level 2 (L2) cache 1875 shared by all or a subset of multi-core groups 1865A-1865N stores graphics data and / or instructions for multiple concurrent graphics threads. As shown in the figure, the L2 cache 1875 can be shared across multiple multi-core groups 1865A-1865N. One or more memory controllers 1867 couple the GPU 1880 to a memory 1866, which can be a system memory (e.g., DRAM) and / or a dedicated graphics memory (e.g., GDDR6 memory).

[0208] Input / output (I / O) circuitry 1863 couples GPU 1880 to one or more I / O devices 1862, such as a digital signal processor (DSP), a network controller, or a user input device. On-chip interconnects may be used to couple I / O devices 1862 to GPU 1880 and memory 1866. One or more I / O memory management units (IOMMUs) 1864 of I / O circuitry 1863 couple I / O devices 1862 directly to system memory 1866. Optionally, IOMMU 1864 manages multiple sets of page tables to map virtual addresses to physical addresses in system memory 1866. I / O devices 1862, CPU 1861, and GPU 1880 may then share the same virtual address space.

[0209] In one embodiment of the IOMMU 1864, the IOMMU 1864 supports virtualization. In this case, it may manage a first set of page tables to map guest / graphics virtual addresses to guest / graphics physical addresses, and may manage a second set of page tables to map guest / graphics physical addresses to system / host physical addresses (e.g., within system memory 1866). The base address of each of the first set of page tables and the second set of page tables may be stored in a control register and swapped out at a context switch (e.g., so that the new context is provided with access to the associated set of page tables). Although in Fig.18C Not illustrated, but each of the cores 1870, 1871, 1872 and / or multi-core groups 1865A-1865N may include a translation lookaside buffer (TLB) to cache guest virtual to guest physical translations, guest physical to host physical translations, and guest virtual to host physical translations.

[0210] The CPU 1861, GPU 1880, and I / O device 1862 may be integrated on a single semiconductor chip and / or chip package. The illustrated memory 1866 may be integrated on the same chip or may be coupled to a memory controller 1867 via an off-chip interface. In one embodiment, the memory 1866 includes GDDR6 memory that shares the same virtual address space with other physical system-level memories, but the basic principles described herein are not limited to this particular embodiment.

[0211] Tensor Core 1871 may include multiple execution units specifically designed to perform matrix operations, which are basic computational operations used to perform deep learning operations. For example, simultaneous matrix multiplication operations can be used for neural network training and reasoning. Tensor Core 1871 can perform matrix processing using a variety of operand precisions, including single-precision floating point (e.g., 32 bits), half-precision floating point (e.g., 16 bits), integer words (16 bits), bytes (8 bits), and half bytes (4 bits). For example, a neural network implementation extracts features of various rendered scenes that potentially combine details from multiple frames to build a high-quality final image.

[0212] In a deep learning implementation, parallel matrix multiplication work may be scheduled for execution on the tensor core 1871. In particular, the training of neural networks requires a large number of matrix dot product operations. To process the inner product formula of the N×N×N matrix multiplication, the tensor core 1871 may include at least N dot product processing elements. Before the matrix multiplication begins, a complete matrix is ​​loaded into the tile register, and at least one column of the second matrix is ​​loaded in each cycle of N cycles. In each cycle, N dot products are processed.

[0213] Matrix elements may be stored with different precisions, including 16-bit words, 8-bit bytes (e.g., INT8), and 4-bit nibbles (e.g., INT4), depending on the particular implementation. Different precision modes may be specified for the tensor core 1871 to ensure the most efficient precision for different workloads (e.g., such as inference workloads that can tolerate quantization to bytes and nibbles). Supported formats additionally include 64-bit floating point (FP64) and non-IEEE floating point formats, such as the bfloat16 format (e.g., brain floating point): a 16-bit floating point format with one sign bit, eight exponent bits, and eight valid bits, of which seven valid bits are explicitly stored. An example includes support for a reduced precision tensor floating (TF32) mode that uses the range of FP32 (8 bits) and the precision of FP16 (10 bits) to perform calculations. Reduced precision TF32 operations may be performed on FP32 inputs and produce FP32 outputs with higher performance relative to FP32 and increased precision relative to FP16. In some examples, one or more 8-bit floating point formats (FP8) are supported.

[0214] In some examples, the tensor core 1871 supports a sparse operation mode for matrices in which the vast majority of values ​​are zero. The tensor core 1871 includes support for sparse input matrices encoded in sparse matrix representations (e.g., coordinate list encoding (COO), compressed sparse rows (CSR), compressed sparse columns (CSC), etc.). The tensor core 1871 also includes support for compressed sparse matrix representations in the case where the sparse matrix representation can be further compressed. Compressed, encoded, and / or compressed and encoded matrix data together with associated compression and / or encoding metadata can be read by the tensor core 1871, and non-zero values ​​can be extracted. For example, for a given input matrix A, non-zero values ​​can be loaded from a compressed and / or encoded representation of at least a portion of matrix A. Based on the position of the non-zero value in matrix A (which can be determined from the index or coordinate metadata associated with the non-zero value), the corresponding value in the input matrix B can be loaded. Depending on the operation to be performed (e.g., multiplication), if the corresponding value is a zero value, the loading of the value from the input matrix B can be bypassed. In some examples, the pairing of values ​​for certain operations, such as multiplication operations, can be pre-scanned by the scheduler logic and only operations between non-zero inputs are scheduled. Depending on the dimensions of matrix A and matrix B and the operations to be performed, the output matrix C can be dense or sparse. In the case where the output matrix C is sparse, depending on the configuration of the tensor core 1871, the output matrix C can be output in a compressed format, sparse coding, or compressed sparse coding.

[0215] The ray tracing core 1872 can accelerate ray tracing operations for real-time ray tracing and non-real-time ray tracing implementations. In particular, the ray tracing core 1872 may include a ray traversal / intersection circuit for performing ray traversal using a bounding box hierarchy (BVH) and identifying intersections between rays and primitives enclosed within the BVH box. The ray tracing core 1872 may also include circuits for performing depth testing and culling (e.g., using a Z buffer or similar arrangement). In one embodiment, the ray tracing core 1872 performs traversal and intersection operations in coordination with the image denoising techniques described herein, and at least a portion of the traversal and intersection operations may be performed on the tensor core 1871. For example, the tensor core 1871 may implement a deep learning neural network to perform denoising on frames generated by the ray tracing core 1872. However, the CPU 1861, the graphics core 1870, and / or the ray tracing core 1872 may also implement all or part of the denoising and / or deep learning algorithms.

[0216] In addition, as described above, a distributed denoising approach may be employed, wherein the GPU 1880 is in a computing device coupled to other computing devices via a network or high-speed interconnect. In this distributed approach, the interconnected computing devices may share neural network learning / training data to increase the speed at which the entire system learns to perform denoising for different types of image frames and / or different graphics applications.

[0217] The ray tracing core 1872 can handle all BVH traversals and / or ray-primitive intersections, thereby avoiding overloading the graphics core 1870 with thousands of instructions per ray. For example, each ray tracing core 1872 includes a first set of dedicated circuits for performing bounding box tests (e.g., for traversal operations) and / or a second set of dedicated circuits for performing ray-triangle intersection tests (e.g., intersecting rays that have been traversed). Thus, for example, the multi-core group 1865A can simply start the ray probe, and the ray tracing core 1872 independently performs ray traversals and intersections and returns hit data (e.g., hits, misses, multiple hits, etc.) to the thread context. While the ray tracing core 1872 performs traversals and intersection operations, the other cores 1870, 1871 are freed up to perform other graphics or computational work.

[0218] Optionally, each ray tracing core 1872 may include a traversal unit that performs BVH test operations and / or a cross unit that performs ray-primitive intersection tests. The cross unit generates a "hit", "miss", or "multiple hits" response, providing the response to the appropriate thread. During traversal and cross operations, execution resources of other cores (e.g., graphics core 1870 and tensor core 1871) are freed to perform other forms of graphics work.

[0219] In some of the examples described below, a hybrid rasterization / ray tracing approach is used in which work is distributed between graphics core 1870 and ray tracing core 1872.

[0220] The ray tracing core 1872 (and / or other cores 1870, 1871) may include hardware support for a ray tracing instruction set such as Microsoft's DirectX Ray Tracing (DXR), which includes the DispatchRays command and ray generation, closest hit, any hit, and miss shaders, which enable the allocation of unique sets of shaders and textures for each object. Another ray tracing platform that can be supported by the ray tracing core 1872, graphics core 1870, and tensor core 1871 is the Vulkan API (e.g., Vulkan version 1.1.85 and later). However, it should be noted that the basic principles described herein are not limited to any particular ray tracing ISA.

[0221] In general, each core 1872, 1871, 1870 may support a ray tracing instruction set that includes instructions / functions for one or more of ray generation, closest hit, any hit, ray-primitive intersection, per-primitive and hierarchy bounding box construction, misses, accesses, and exceptions. More specifically, some examples include ray tracing instructions that perform one or more of the following functions:

[0222] -Ray Generation -Ray generation instructions can be executed for each pixel, sample, or other user-defined work distribution.

[0223] - Closest Hit - A closest hit instruction may be executed to locate the closest intersection of a ray with a primitive within a scene.

[0224] -Any Hit - The Any Hit instruction identifies multiple intersections between rays and primitives within the scene to potentially identify a new closest intersection point.

[0225] -Cross-The -Cross instruction performs a ray-primitive intersection test and outputs the result.

[0226] - Per-primitive bounding box construction - This instruction builds a bounding box around a given primitive or group of primitives (eg, when building a new BVH or other acceleration data structure).

[0227] -Miss - Indicates that the ray missed all geometry within the scene or a specified area of ​​the scene.

[0228] -Visit - Indicates the subbox that the ray will pass through.

[0229] -Exceptions - includes various types of exception handlers (e.g., called for various error conditions).

[0230] In some examples, the ray tracing core 1872 can be adapted to accelerate general computing operations that can be accelerated using computing techniques similar to ray crossing tests. A computing framework can be provided that enables shader programs to be compiled into low-level instructions and / or primitives that perform general computing operations via the ray tracing core. Exemplary computing problems that can benefit from computing operations performed on the ray tracing core 1872 include calculations involving beam, wave, light, or particle propagation in a coordinate space. Interactions associated with the propagation can be calculated relative to a geometry or grid in a coordinate space. For example, calculations associated with the propagation of electromagnetic signals through an environment can be accelerated using instructions or primitives executed via a ray tracing core. The diffraction and reflection of the signal by objects in the environment can be calculated as a direct ray tracing analogy.

[0231] The ray tracing core 1872 can also be used to perform calculations that are not directly similar to ray tracing. For example, the ray tracing core 1872 can be used to accelerate mesh projection, mesh refinement, and volume sampling calculations. General coordinate space calculations, such as nearest neighbor calculations, can also be performed. For example, a set of points near a given point can be found by defining a bounding box in the coordinate space around the point. Then, the BVH and ray detection logic within the ray tracing core 1872 can be used to determine the set of intersections of points within the bounding box. The intersection constitutes the origin and the nearest neighbor of the origin. The calculations performed using the ray tracing core 1872 can be performed in parallel with the calculations performed on the graphics core 1872 and the tensor core 1871. The shader compiler can be configured to compile a compute shader or other general graphics processing program into a low-level primitive that can be parallelized across the graphics core 1870, the tensor core 1871, and the ray tracing core 1872.

[0232] Building larger and larger silicon dies is challenging for a variety of reasons. As silicon dies get larger, manufacturing yields get smaller, and the process technology requirements for different components may be different. On the other hand, in order to have a high-performance system, key components should be interconnected through high-speed, high-bandwidth, low-latency interfaces. These conflicting requirements pose challenges to the development of high-performance chips.

[0233] The embodiments described herein provide techniques that decompose the architecture of a system-on-chip integrated circuit into multiple different chiplets that can be packaged onto a common chassis. In some examples, a graphics processing unit or a parallel processor consists of different silicon chiplets that are manufactured separately. A chiplet is an integrated circuit that is at least partially packaged and includes different logic units that can be assembled with other chiplets into a larger package. Different groups of chiplets with different IP core logic can be assembled into a single device. In addition, chiplets can be integrated into a base die or base chiplet using active inserter technology. The concepts described herein enable interconnection and communication between different forms of IP within a GPU. Developing IP on different processes can be mixed. This avoids the complexity of converging multiple IPs, especially multiple IPs on a large SoC with several flavors of IP, to the same process.

[0234] Enabling the use of multiple process technologies improves time to market and provides a cost-effective way to create multiple product SKUs. For customers, this means getting products that are more tailored to their needs in a cost-effective and timely manner. In addition, decomposed IP is more easily power-gated independently, and components that are not used on a given workload can be powered off, reducing overall power consumption.

[0235] Fig.19A parallel computing system 1900 according to some examples is illustrated. In some examples, the parallel computing system 1900 includes a parallel processor 1920, which may be a graphics processor or a computing accelerator as described herein. The parallel processor 1920 includes a global logic unit 1901, an interface 1902, a thread dispatcher 1903, a media unit 1904, a group of computing units 1905A-1905H, and a cache / memory unit 1906. In some examples, the global logic unit 1901 includes global functions for the parallel processor 1920, including device configuration registers, a global scheduler, power management logic, etc. The interface 1902 may include a front-end interface for the parallel processor 1920. The thread dispatcher 1903 may receive a workload from the interface 1902 and dispatch threads for the workload to the computing units 1905A-1905H. If the workload includes any media operations, at least a portion of these operations may be performed by the media unit 1904. The media unit may also offload some operations to the compute units 1905A-1905H. The cache / memory unit 1906 may include cache memory (eg, L3 cache) and local memory (eg, HBM, GDDR) for the parallel processors 1920.

[0236] FIG. 20A to FIG. 20B A hybrid logical / physical view of a factorized parallel processor according to examples described herein is illustrated. Fig. 20A A decomposed parallel computing system 2000 is illustrated. Fig. 20B A chiplet 2030 of the decomposed parallel computing system 2000 is illustrated.

[0237] like Fig. 20A As shown, the decomposed computing system 2000 may include a parallel processor 2020, wherein the various components of the parallel processor SOC are distributed across multiple chiplets. Each chiplet may be a different IP core that is independently designed and configured to communicate with other chiplets via one or more common interfaces. The chiplets include, but are not limited to, a computing chiplet 2005, a media chiplet 2004, and a memory chiplet 2006. Each chiplet may be manufactured separately using different process technologies. For example, the computing chiplet 2005 may be manufactured using the smallest or most advanced process technology available at the time of manufacturing, while the memory chiplet 2006 or other chiplets (e.g., I / O, networking, etc.) may be manufactured using a larger or less advanced process technology.

[0238] Various chiplets may be bonded to a base die 2010 and configured to communicate with each other and logic within the base die 2010 via an interconnect layer 2012. In some examples, the base die 2010 may include a global logic 2001, which may include a scheduler 2011 and power management 2021 logic unit, an interface 2002, a dispatch unit 2003, and an interconnect fabric module 2008 coupled or integrated with one or more L3 cache banks 2009A-2009N. The interconnect fabric 2008 may be an inter-chiplet fabric integrated into the base die 2010. The fabric 2008 may be used by the logic chiplets to relay messages between the various chiplets. Additionally, the L3 cache banks 2009A-2009N in the base die and / or the L3 cache banks within the memory chiplet 2006 may cache data read from and sent to the DRAM chiplets within the memory chiplet 2006 and data read from and sent to the system memory of the host.

[0239] In some examples, the global logic 2001 is a microcontroller that can execute firmware to perform scheduler 2011 and power management 2021 functions for the parallel processor 2020. The microcontroller executing the global logic can be customized for the target use case of the parallel processor 2020. The scheduler 2011 can perform global scheduling operations for the parallel processor 2020. The power management 2021 function can be used to enable or disable individual chiplets within the parallel processor when they are not being used.

[0240] The individual chiplets of the parallel processor 2020 may be designed to perform a specific function that would be integrated into a single die in existing designs. A set of compute chiplets 2005 may include a cluster of compute units (e.g., execution units, streaming multiprocessors, etc.) that include programmable logic to execute compute or graphics shader instructions. Media chiplets 2004 may include hardware logic to accelerate media encoding and decoding operations. Memory chiplets 2006 may include volatile memory (e.g., DRAM) and one or more SRAM cache banks (e.g., L3 banks).

[0241] like Fig. 20BAs shown, each chiplet 2030 may include common components and dedicated components. The chiplet logic 2036 within the chiplet 2030 may include specific components of the chiplet, such as an array of streaming multiprocessors, computing units, or execution units described herein. The chiplet logic 2036 may be coupled with an optional cache or shared local memory 2038, or a cache or shared local memory may be included in the chiplet logic 2036. The chiplet 2030 may include a fabric interconnect node 2042 that receives commands via an inter-chiplet fabric. Commands and data received via the fabric interconnect node 2042 may be temporarily stored in an interconnect buffer 2039. Data sent to and received from the fabric interconnect node 2042 may be stored in the interconnect cache 2040. Power control 2032 and clock control 2034 logic may also be included within the chiplet. The power control 2032 and clock control 2034 logic may receive configuration commands via a fabric that may configure dynamic voltage and frequency scaling of the chiplet 2030. In some examples, individual chiplets can have independent clock and power domains and can be clock-gated and power-gated independently of other chiplets.

[0242] At least a portion of the components within the illustrated chiplet 2030 may also be included in an embedded Fig. 20A The base die 2010 may be within logic within the base die 2010. For example, logic within the base die that communicates with the fabric may include a version of the fabric interconnect node 2042. The base die logic that may be independently clocked or power gated may include a version of the power control 2032 and / or clock control 2034 logic.

[0243] Thus, while various examples described herein use the term SOC to describe a device or system having a processor and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, memory circuitry, etc.) integrally integrated into a single integrated circuit (“IC”) die or chip, the present disclosure is not limited in this regard. For example, in various examples of the present disclosure, a device or system may have one or more processors (e.g., one or more processor cores) and associated circuitry (e.g., input / output (“I / O”) circuitry, power delivery circuitry, etc.) arranged in a disaggregated collection of discrete dies, tiles, and / or chiplets (e.g., one or more discrete processor core dies arranged adjacent to one or more other dies such as memory dies, I / O dies, etc.). In such disaggregated devices and systems, the various dies, tiles, and / or chiplets may be physically and electrically coupled together by a packaging structure including, for example, various packaging substrates, interposers, active interposers, photonic interposers, interconnect bridges, etc. A disaggregated collection of discrete dies, tiles, and / or chiplets may also be part of a system on a package ("SoP").

[0244] Example core architectures - in-order and out-of-order core block diagrams.

[0245] FIG. 21(A) is a block diagram illustrating both an example in-order pipeline and an example register renaming, out-of-order issue / execution pipeline according to an example. FIG. 21(B) is a block diagram illustrating both an example in-order architecture core and an example register renaming, out-of-order issue / execution architecture core to be included in a processor according to an example. The solid-line boxes in FIG. 21(A) to FIG. 21(B) illustrate the in-order pipeline and the in-order core, while the optional addition of the dashed-line boxes illustrates the register renaming, out-of-order issue / execution pipeline and the core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0246] In FIG. 21(A), the processor pipeline 2100 includes an acquisition stage 2102, an optional length decoding stage 2104, a decoding stage 2106, an optional allocation (Alloc) stage 2108, an optional renaming stage 2110, a scheduling (also called dispatch or issue) stage 2112, an optional register read / memory read stage 2114, an execution stage 2116, a write-back / memory write stage 2118, an optional exception handling stage 2122, and an optional submission stage 2124. One or more operations may be performed in each of these processor pipeline stages. For example, during the acquisition stage 2102, one or more instructions are acquired from the instruction memory, and during the decoding stage 2106, one or more acquired instructions may be decoded, an address using a forwarded register port (e.g., a load storage unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In some examples, the decoding stage 2106 and the register read / memory read stage 2114 may be combined into one pipeline stage. In some examples, during the execute stage 2116, decoded instructions may be executed, LSU address / data pipelining to an advanced microcontroller bus (AMB) interface may be performed, multiplication and addition operations may be performed, arithmetic operations with branch results may be performed, and the like.

[0247] By way of example, the example register renaming, out-of-order issue / execution architecture core of FIG. 21(B) may implement pipeline 2100 as follows: 1) instruction fetch circuit 2138 performs fetch and length decoding stages 2102 and 2104; 2) decoding circuit 2140 performs decoding stage 2106; 3) renaming / allocator unit circuit 2152 performs allocation stage 2108 and renaming stage 2110; 4) scheduler circuit 2156 performs scheduling stage 2112; 5) physical register file circuit 2158 and memory unit circuit 2170 perform register read / memory read stage 2114; execution cluster 2160 executes stage 2116; 6) memory unit circuit 2170 and physical register file circuit 2158 perform write back / memory write stage 2118; 7) various circuits may be involved in exception handling stage 2122; and 8) retirement unit circuit 2154 and physical register file circuit 2158 perform commit stage 2124.

[0248] 21(B) shows a processor core 2190, which includes a front end unit circuit 2130 coupled to an execution engine unit circuit 2150, and both are coupled to a memory unit circuit 2170. The core 2190 can be a reduced instruction set architecture computing (RISC) core, a complex instruction set architecture computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 2190 can be a dedicated core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, etc.

[0249] The front end unit circuit 2130 may include a branch prediction circuit 2132 coupled to an instruction cache circuit 2134, which is coupled to an instruction translation lookaside buffer (TLB) 2136, which is coupled to an instruction fetch circuit 2138, which is coupled to a decoding circuit 2140. In some examples, the instruction cache circuit 2134 is included in the memory unit circuit 2170 instead of the front end circuit 2130. The decoding circuit 2140 (or decoder) can decode the instruction and generate one or more micro-operations, microcode entry points, microinstructions, other instructions or other control signals as output, which are decoded from the original instruction or otherwise reflect the original instruction or are derived from the original instruction. The decoding circuit 2140 may also include an address generation unit (AGU, not shown) circuit. In some examples, the AGU generates an LSU address using a forwarded register port, and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decoding circuit 2140 can be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memories (ROMs), etc. In some examples, core 2190 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in decode circuitry 2140 or otherwise within front-end circuitry 2130). In some examples, decode circuitry 2140 includes a micro-operation (micro-op) or operation cache (not shown) to hold / cache decode operations, micro-tags, or micro-ops generated during decode or other stages of processor pipeline 2100. Decode circuitry 2140 may be coupled to rename / allocator unit circuitry 2152 in execution engine circuitry 2150.

[0250] The execution engine circuit 2150 includes a rename / allocator unit circuit 2152 coupled to a retirement unit circuit 2154 and a set of one or more scheduler circuits 2156. The scheduler circuit 2156 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some examples, the scheduler circuit 2156 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an address generation unit (AGU) scheduler / scheduling circuit, an AGU queue, and the like. The scheduler circuit 2156 is coupled to a physical register file circuit 2158. Each physical register file circuit 2158 represents one or more physical register files, where different physical register files store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., an instruction pointer that is the address of the next instruction to be executed), and the like. In some examples, the physical register file circuit 2158 includes a vector register unit circuit, a write mask register unit circuit, and a scalar register unit circuit. These register units may provide architectural vector registers, vector mask registers, general purpose registers, etc. Physical register file circuitry 2158 is coupled to retirement unit circuitry 2154 (also referred to as a retirement queue) to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer (ROB) and a retirement register file; using a future file, a history buffer, and a retirement register file; using a register map and a register pool, etc.). Retirement unit circuitry 2154 and physical register file circuitry 2158 are coupled to execution cluster 2160. Execution cluster 2160 includes a set of one or more execution unit circuitry 2162 and a set of one or more memory access circuitry 2164. Execution unit circuitry 2162 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some examples may include multiple execution units or execution unit circuits dedicated to a particular function or set of functions, other examples may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions. Scheduler circuit 2156, physical register file circuit 2158, and execution cluster 2160 are shown as potentially multiple because some examples create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipelines, and / or memory access pipelines, each with its own scheduler circuit, physical register file circuit, and / or execution cluster—and in the case of a separate memory access pipeline, some examples are implemented in which only the execution cluster of that pipeline has a memory access unit circuit 2164).It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution while the rest are in-order.

[0251] In some examples, execution engine unit circuit 2150 may perform load store unit (LSU) address / data pipelining, as well as address stage and write back, data stage load, store, and branch to an advanced microcontroller bus (AMB) interface (not shown).

[0252] The set of memory access circuits 2164 is coupled to the memory cell circuit 2170, which includes a data TLB circuit 2172 coupled to a data cache circuit 2174, which is coupled to a level 2 (L2) cache circuit 2176. In some examples, the memory access circuit 2164 may include a load unit circuit, a store address unit circuit, and a store data unit circuit, each of which is coupled to the data TLB circuit 2172 in the memory cell circuit 2170. The instruction cache circuit 2134 is also coupled to the level 2 (L2) cache circuit 2176 in the memory cell circuit 2170. In some examples, the instruction cache 2134 and the data cache 2174 are combined into a single instruction and data cache (not shown) in the L2 cache circuit 2176, the level 3 (L3) cache circuit (not shown), and / or the main memory. The L2 cache circuit 2176 is coupled to one or more other levels of cache and ultimately to the main memory.

[0253] Core 2190 may support one or more instruction sets (e.g., x86 instruction set architecture (optionally with some extensions that have been added to newer versions); MIPS instruction set architecture; ARM instruction set architecture (optionally with optional additional extensions such as NEON)), including the instructions described herein. In some examples, core 2190 includes logic to support packed data instruction set architecture extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using packed data.

[0254] Example execution unit circuit.

[0255] Fig. 22An example of an execution unit circuit such as the execution unit circuit 2162 of FIG. 21 (B) is illustrated. As illustrated, the execution unit circuit 2162 may include one or more ALU circuits 2201, optional vector / single instruction multiple data (SIMD) circuits 2203, load / store circuits 2205, branch / jump circuits 2207, and / or floating point unit (FPU) circuits 2209. The ALU circuit 2201 performs integer operations and / or Boolean operations. The vector / SIMD circuit 2203 performs vector / SIMD operations on packed data (such as SIMD / vector registers). The load / store circuit 2205 executes load and store instructions to load data from a memory into a register or store data from a register to a memory. The load / store circuit 2205 may also generate an address. The branch / jump circuit 2207 causes a branch or jump to a memory address according to the instruction. The FPU circuit 2209 performs floating point operations. The width of execution unit circuit 2162 varies according to examples and can range from, for example, 16 bits to 1024 bits. In some examples, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0256] Example register architecture.

[0257] Fig.23 2300 is a block diagram of a register architecture 2300 according to some examples. As illustrated, the register architecture 2300 includes a vector / SIMD register 2310 that varies from a 128-bit width to a 1024-bit width. In some examples, the vector / SIMD register 2310 is physically 512 bits, and according to the mapping, only some lower bits are used. For example, in some examples, the vector / SIMD register 2310 is a 512-bit ZMM register: the lower 256 bits are used for the YMM register, and the lower 128 bits are used for the XMM register. It can be seen that there is an overlay of registers. In some examples, the vector length field is selected between the maximum length and one or more other shorter lengths, wherein each such shorter length is half of the previous length. Scalar operations are operations performed on the lowest bit data element position in the ZMM / YMM / XMM register; according to the example, the higher bit data element positions are either the same as they were before the instruction, or are reset to zero.

[0258] In some examples, the register architecture 2300 includes a write mask / predicate register 2315. For example, in some examples, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate register 2315 may allow merging (e.g., allowing any set of elements in the destination to be protected from update during the execution of any operation) and / or zeroing (e.g., zeroing the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some examples, each data element position in a given write mask / predicate register 2315 corresponds to a data element position in the destination. In other examples, the write mask / predicate register 2315 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits per 64-bit vector element).

[0259] The register architecture 2300 includes a plurality of general registers 2325. These registers may be 16-bit, 32-bit, 64-bit, etc., and may be used for scalar operations. In some examples, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0260] In some examples, the register architecture 2300 includes a scalar floating point (FP) register file 2345, which is used to perform scalar floating point operations on 32 / 64 / 80-bit floating point data using the x87 instruction set architecture extension, or used as an MMX register to perform operations on 64-bit packed integer data, and to hold operands for some operations performed between MMX and XMM registers.

[0261] One or more flag registers 2340 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 2340 can store condition code information such as carry, parity, auxiliary carry, zero, sign, and overflow. In some examples, one or more flag registers 2340 are referred to as program status and control registers.

[0262] Segment registers 2320 contain segment points for accessing memory. In some examples, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.

[0263] Model-specific registers or machine-specific registers (MSRs) 2335 control and report processor performance. Most MSRs 2335 handle system-related functions and cannot be accessed by applications. For example, MSRs can provide control of one or more of the following: performance monitoring counters, debug extensions, memory type range registers, thermal and power management, instruction-specific support, and / or processor feature / mode support. Machine check registers 2360 include control, status, and error reporting MSRs for detecting and reporting hardware errors. Control registers 2355 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processors 1470, 1480, 1438, 1415, and / or 1500) and the characteristics of the currently executing task. In some examples, MSRs 2335 are a subset of control registers 2355.

[0264] One or more instruction pointer registers 2330 store instruction pointer values. Debug registers 2350 control and allow monitoring of debug operations of the processor or core.

[0265] Memory (mem) management registers 2365 specify the location of data structures used in protected mode memory management. These registers may include the global descriptor table register (GDTR), the interrupt descriptor table register (IDTR), the task register, and the local descriptor table register (LDTR).

[0266] Alternative examples may use wider or narrower registers. In addition, alternative examples may use more, fewer, or different register files and registers. Register architecture 2300 may be used, for example, in register file / memory 708 or physical register file circuit 2158.

[0267] Instruction set architecture.

[0268] Instruction set architecture (ISA) can include one or more instruction formats. A given instruction format can define various fields (e.g., the number of bits, the position of bits) to specify the operation to be performed (e.g., opcode) and the operands and / or other data fields (e.g., masks) on which the operation is to be performed. Some instruction formats are further decomposed by the definition of instruction templates (or sub-formats). For example, an instruction template of a given instruction format can be defined as having different subsets of fields of the instruction format (the fields included are usually in the same order, but at least some fields have different bit positions because fewer fields are included) and / or defined as having given fields interpreted differently. Thus, each instruction of the ISA is expressed using a given instruction format (and if defined, in a given one of the instruction templates of the instruction format), and includes fields for specifying operations and operands. For example, an example ADD instruction has a specific opcode and instruction format, which includes an opcode field specifying the opcode and an operand field for selecting operands (source 1 / destination and source 2); and the occurrence of this ADD instruction in an instruction stream will have specific content in the operand field for selecting a specific operand. Additionally, although the following description is made in the context of the x86 ISA, it is within the purview of those skilled in the art to apply the teachings of the present disclosure in another ISA.

[0269] Example instruction format.

[0270] The examples of instructions described herein may be implemented in different formats. In addition, example systems, architectures, and pipelines are described in detail below. The examples of instructions may be executed on such systems, architectures, and pipelines, but are not limited to those described in detail.

[0271] Fig.24 An example of an instruction format is illustrated. As illustrated, an instruction may include multiple components, including, but not limited to, one or more fields for: one or more prefixes 2401, an opcode 2403, addressing information 2405 (e.g., a register identifier, memory addressing information, etc.), a displacement value 2407, and / or an immediate value 2409. It should be noted that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 2403 field. In some examples, the illustrated order is the order in which these fields are to be encoded, however, it should be understood that in other examples, these fields may be encoded in a different order, combined, etc.

[0272] Prefix field 2401 modifies instructions when used. In some examples, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), to provide partial coverage (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), perform bus lock operations, and / or change operands (e.g., 0x66) and address sizes (e.g., 0x67). Certain instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. Other prefixes generally follow the "traditional" prefix.

[0273] The opcode field 2403 is used to at least partially define the operation to be performed when decoding the instruction. In some examples, the length of the primary opcode encoded in the opcode field 2403 is one, two or three bytes. In other examples, the primary opcode can be a different length. Sometimes an additional 3-bit opcode field is encoded in another field.

[0274] The addressing information field 2405 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Fig.25 An example of an addressing information field 2405 is illustrated. In this illustration, an optional MOD R / M byte 2502 and an optional scale, index, base (SIB) byte 2504 are shown. The MOD R / M byte 2502 and SIB byte 2504 are used to encode up to two operands of the instruction, each operand being a direct register or an effective memory address. It should be noted that both of these fields are optional, as not all instructions include one or more of these fields. The MOD R / M byte 2502 includes a MOD field 2542, a register (reg) field 2544, and an R / M field 2546.

[0275] The content of MOD field 2542 distinguishes between memory access and non-memory access modes. In some examples, when MOD field 2542 has a binary value of 11 (11b), register direct addressing mode is used, otherwise register indirect addressing mode is used.

[0276] Register field 2544 may encode a destination register operand or a source register operand, or may encode an opcode extension and is not used to encode any instruction operand. The contents of register field 2544 specify the location (in a register or in memory) of the source or destination operand directly or through address generation. In some examples, register field 2544 is supplemented with additional bits from a prefix (e.g., prefix 2401) to allow for greater addressing.

[0277] R / M field 2546 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that in some examples, R / M field 2546 may be combined with MOD field 2542 to indicate an addressing mode.

[0278] SIB byte 2504 includes a scaling field 2552, an index field 2554, and a base address field 2556 used in the generation of the address. Scaling field 2552 indicates a scaling factor. Index field 2554 specifies the index register to be used. In some examples, index field 2554 is supplemented with additional bits from a prefix (e.g., prefix 2401) to allow for larger addressing. Base address field 2556 specifies the base address register to be used. In some examples, base address field 2556 is supplemented with additional bits from a prefix (e.g., prefix 2401) to allow for larger addressing. In practice, the content of scaling field 2552 allows the content of index field 2554 to be scaled for memory address generation (e.g., for address generation using 2 scaling * index + base address).

[0279] Some addressing forms utilize displacement values ​​to generate memory addresses. For example, memory addresses may be generated based on 2 scaling * index + base address + displacement, index * scaling + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. The displacement may be a value of 1 byte, 2 bytes, 4 bytes, etc. In some examples, the displacement field 2407 provides the value. Additionally, in some examples, the displacement factor usage is encoded in the MOD field of the addressing information field 2405, which indicates a compressed displacement scheme for which the displacement value is calculated and stored in the displacement field 2407.

[0280] In some examples, the immediate value field 2409 specifies the immediate value of the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

[0281] Fig.26 An example of a first prefix 2401(A) is illustrated. In some examples, the first prefix 2401(A) is an example of a REX prefix. Instructions using this prefix can specify general registers, 64-bit packed data registers (e.g., single instruction multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0282] Instructions using the first prefix 2401(A) can specify up to three registers using 3-bit fields depending on the format: 1) using the register field 2544 and the R / M field 2546 of the MOD R / M byte 2502; 2) using the MODR / M byte 2502 with the SIB byte 2504, including using the register field 2544 as well as the base address field 2556 and the index field 2554; or 3) using the register field of the opcode.

[0283] In the first prefix 2401 (A), the bit positions of payload bytes 7:4 are set to 0100. Bit position 3 (W) can be used to determine the operand size, but can determine more than just the operand width. It can be seen that when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0284] Note that the addition of another bit allows addressing of 16 (2 4 ) registers, while the MOD R / M register field 2544 and the MOD R / MR / M field 2546 alone can each address only 8 registers.

[0285] In the first prefix 2401(A), bit position 2 (R) may be an extension of the MOD R / M register field 2544 and may be used to modify the MOD R / M register field 2544 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the MOD R / M byte 2502 specifies other registers or defines an extended opcode, R is ignored.

[0286] Bit position 1 (X) may modify the SIB byte index field 2554 .

[0287] Bit position 0 (B) may modify the base address in the MOD R / MR / M field 2546 or the SIB byte base address field 2556; or it may modify the opcode register field used to access a general register (eg, general register 2325).

[0288] 27(A) to 27(D) illustrate examples of how the R, X, and B fields of the first prefix 2401(A) are used. FIG27(A) illustrates the use of R and B from the first prefix 2401(A) to extend the register field 2544 and R / M field 2546 of the MOD R / M byte 2502 when the SIB byte 2504 is not used for memory addressing. FIG27(B) illustrates the use of R and B from the first prefix 2401(A) to extend the register field 2544 and R / M field 2546 of the MOD R / M byte 2502 when the SIB byte 2504 is not used (register-register addressing). 27(C) illustrates that the register field 2544 of the MOD R / M byte 2502 and the index field 2554 and base field 2556 are extended using R, X, and B from the first prefix 2401(A) when the SIB byte 2504 is used for memory addressing. FIG27(D) illustrates that the register field 2544 of the MOD R / M byte 2502 is extended using B from the first prefix 2401(A) when the register is encoded in the opcode 2403.

[0289] Figures 28(A) to 28(B) illustrate examples of second prefix 2401(B). In some examples, second prefix 2401(B) is an example of a VEX prefix. Second prefix 2401(B) encoding allows instructions to have more than two operands, and allows SIMD vector registers (e.g., vector / SIMD registers 2310) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of second prefix 2401(B) provides a three-operand (or more) syntax. For example, the previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of second prefix 2401(B) enables operands to perform non-destructive operations such as A=B+C.

[0290] In some examples, the second prefix 2401(B) appears in two forms - a two-byte form and a three-byte form. The two-byte second prefix 2401(B) is primarily used for 128-bit, scalar, and some 256-bit instructions; while the three-byte second prefix 2401(B) provides a compact replacement for the first prefix 2401(A) with 3-byte opcode instructions.

[0291] Figure 28 (A) illustrates an example of a two-byte form of the second prefix 2401 (B). In some examples, the format field 2801 (byte 0 2803) contains the value C5H. In some examples, byte 1 2805 includes an "R" value in position [7]. This value is the complement of the "R" value of the first prefix 2401 (A). Position [2] is used to indicate the length (L) of the vector (wherein value 0 is a scalar or 128-bit vector and value 1 is a 256-bit vector). Position [1:0] provides an opcode extension equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand specified in reverse (1s complement) form and valid for instructions with 2 or more source operands; 2) encode a destination register operand specified in 1s complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain some value, such as 1111b.

[0292] Instructions using this prefix may use the MOD R / MR / M field 2546 to encode an instruction operand that references a memory address or to encode a destination register operand or a source register operand.

[0293] Instructions using this prefix may use the MOD R / M register field 2544 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0294] For instruction syntax supporting four operands, vvvv, MOD R / MR / M field 2546, and MOD R / M register field 2544 encode three of the four operands. Bits [7:4] of immediate value field 2409 are then used to encode the third source register operand.

[0295] Figure 28 (B) illustrates an example of a three-byte form of the second prefix 2401 (B). In some examples, the format field 2811 (byte 0 2813) contains the value C4H. Byte 1 2815 includes "R", "X" and "B" in position [7:5], which are the complements of the same value of the first prefix 2401 (A). Position [4:0] of byte 1 2815 (shown as mmmm) includes the content of one or more implicit leading opcode bytes encoded as needed. For example, 00001 means 0FH leading opcode, 00010 means 0F38H leading opcode, 00011 means 0F3AH leading opcode, and so on.

[0296] Bit [7] of byte 2 2817 is used similarly to W of the first prefix 2401 (A), including helping to determine the size of operands that can be promoted. Bit [2] is used to indicate the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensions equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand specified in reverse (1s complement) form and valid for instructions with 2 or more source operands; 2) encode a destination register operand specified in 1s complement form for certain vector shifts; or 3) do not encode any operands, this field is reserved and should contain a value such as 1111b.

[0297] Instructions using this prefix may use the MOD R / MR / M field 2546 to encode an instruction operand that references a memory address or to encode a destination register operand or a source register operand.

[0298] Instructions using this prefix may use the MOD R / M register field 2544 to encode a destination register operand or a source register operand, or be treated as an opcode extension and not used to encode any instruction operand.

[0299] For instruction syntax supporting four operands, vvvv, MOD R / MR / M field 2546, and MOD R / M register field 2544 encode three of the four operands. Bits [7:4] of immediate value field 2409 are then used to encode the third source register operand.

[0300] Fig.29 An example of a third prefix 2401(C) is illustrated. In some examples, the third prefix 2401(C) is an example of an EVEX prefix. The third prefix 2401(C) is a four-byte prefix.

[0301] The third prefix 2401(C) may encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some examples, write masks / operation masks are used (see, for example, Fig.23 The prefix is ​​used by instructions that are not intended to be used for conditional processing or selection control (e.g., the discussion of registers in the previous figures of FIG. 2401 ) or predicted by the operator. The operator mask register allows conditional processing or selection control. The second prefix 2401 (B) is used to encode an operator mask instruction whose source / destination operand is an operator mask register and the contents of the operator mask register are treated as a single value.

[0302] The third prefix 2401(C) may encode functionality specific to the instruction class (e.g., a packed instruction with “load+operation” semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a “suppress all exceptions” functionality, etc.).

[0303] The first byte of the third prefix 2401 (C) is the format field 2911, which in some examples has a value of 62 H. Subsequent bytes are referred to as payload bytes 2915-2919 and together form a 24-bit value P[23:0], which provides specific capabilities in the form of one or more fields (described in detail herein).

[0304] In some examples, P[1:0] of the payload byte 2919 is the same as the lower two mm bits. In some examples, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register groups when combined with P[7] and the MOD R / M register field 2544. When SIB type addressing is not required, P[6] can also provide access to the upper 16 vector registers. P[7:5] includes R, X, and B, which are operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with the MOD R / M register field 2544 and the MOD R / MR / M field 2546, allows access to the next group of 8 registers outside the lower 8 registers. P[9:8] provides an opcode extension equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). In some examples, P

[10] is a fixed value of 1. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand specified in reverse (1s complement) form and valid for instructions with 2 or more source operands; 2) encode a destination register operand specified in 1s complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain some value, such as 1111b.

[0305] P

[15] is similar to W of the first prefix 2401 (A) and the second prefix 2411 (B), and can be used as an opcode extension bit or operand size promotion.

[0306] P[18:16] specifies the index of a register in an operation mask (write mask) register (e.g., write mask / predicate register 2315). In some examples, a particular value aaa=000 has special behavior that implies that no operation mask is used for a particular instruction (this can be implemented in various ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from being updated during the execution of any operation (specified by the base operation and the augmentation operation); in some other examples, the old values ​​of the individual elements of the destination are retained when the corresponding mask bits have a 0. Conversely, when zeroing the vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the base operation and the augmentation operation); in some examples, when the corresponding mask bits have a 0 value, the elements of the destination are set to 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the span from the first to the last element modified); however, the modified elements do not have to be consecutive. Thus, the operation mask field enables partial vector operations, including loads, stores, arithmetic, logical, etc. Although examples are described in which the contents of the operation mask field select one of a plurality of operation mask registers containing an operation mask to be used (and whereby the contents of the operation mask field indirectly identify the masking to be performed), alternative examples instead or additionally allow the contents of the mask write field to directly specify the masking to be performed.

[0307] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can use P

[19] to access the upper 16 vector registers. P

[20] encodes multiple features that are different across different instruction classes and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merge write masking (e.g., when set to 0) or support for zeroing and merge write masking (e.g., when set to 1).

[0308] An example of using the third prefix 2401 (C) to encode a register in an instruction is described in detail in the following table.

[0309]

[0310] Table 1: 32-register support in 64-bit mode

[0311]

[0312] Table 2: Encoded register specifiers in 32-bit mode

[0313]

[0314]

[0315] Table 3: Operation Mask Register Specifier Encoding

[0316] Graphics Execution Unit

[0317] FIG. 30A to FIG. 30B Thread execution logic 3000 is illustrated including an array of processing elements employed in a graphics processor core according to examples described herein. FIG. 30A to FIG. 30B Elements in the drawings having the same reference numbers (or names) as elements of any other figures herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto. Fig. 30A represents an execution unit within a general-purpose graphics processor, and Fig. 30B Represents an execution unit that can be used within a compute accelerator.

[0318] like Fig. 30A As an example, in some examples, thread execution logic 3000 includes a shader processor 3002, a thread dispatcher 3004, an instruction cache 3006, a scalable execution unit array including a plurality of execution units 3008A-3008N, a sampler 3010, a shared local memory 3011, a data cache 3012, and a data port 3014. In some examples, the scalable execution unit array can be dynamically scaled by enabling or disabling one or more execution units (e.g., any one of execution units 3008A, 3008B, 3008C, 3008D to 3008N-1 and 3008N) based on the computational requirements of the workload. In some examples, the included components are interconnected via an interconnect structure connected to the various components. In some examples, thread execution logic 3000 includes one or more connections to a memory such as system memory or cache memory through instruction cache 3006, data port 3014, sampler 3010, and one or more of execution units 3008A-3008N. In some examples, each execution unit (e.g., 3008A) is an independent programmable general-purpose computing unit that is capable of executing multiple simultaneous hardware threads while processing multiple data elements in parallel for each thread. In various examples, the array of execution units 3008A-3008N is scalable to include any number of separate execution units.

[0319] In some examples, execution units 3008A to 3008N are primarily used to execute shader programs. Shader processor 3002 can process various shader programs and dispatch execution threads associated with shader programs via thread dispatcher 3004. In some examples, thread dispatcher includes logic that arbitrates thread initiation requests from graphics and media pipelines and instantiates the requested threads on one or more execution units in execution units 3008A-3008N. For example, a geometry pipeline can dispatch vertex, tessellation, or geometry shaders to thread execution logic for processing. In some examples, thread dispatcher 3004 can also process runtime thread derivative requests from executing shader programs.

[0320] In some examples, execution units 3008A-3008N support an instruction set including native support for many standard 3D graphics shader instructions, so that shader programs from graphics libraries (e.g., Direct 3D and OpenGL) are executed with minimal translation. The execution unit supports vertex and geometry processing (e.g., vertex programs, geometry programs, vertex shaders), pixel processing (e.g., pixel shaders, fragment shaders), and general processing (e.g., compute and media shaders). Each of the execution units 3008A-3008N is capable of multi-issue single instruction multiple data (SIMD) execution, and multi-threaded operations achieve an efficient execution environment in the face of high latency memory access. Each hardware thread within each execution unit has a dedicated high-bandwidth register stack and an associated independent thread state. Execution is multi-issue per clock to a pipeline capable of integer, single-precision and double-precision floating-point operations, SIMD branching capabilities, logical operations, transcendental operations, and other miscellaneous operations. While waiting for data from one of the memory or shared functions, the dependency logic within the execution units 3008A-3008N puts the waiting thread to sleep until the requested data has been returned. While the waiting thread is sleeping, hardware resources can be devoted to processing other threads. For example, during a delay associated with a vertex shader operation, the execution unit can perform operations of a pixel shader, a fragment shader, or another type of shader program (including different vertex shaders). Various examples can be applied to using execution by using single instruction multiple threads (SIMT), as an alternative to using SIMD or in addition to using SIMD. References to SIMD cores or operations can also be applied to SIMT or to a combination of SIMD and SIMT.

[0321] Each of the execution units 3008A-3008N operates on an array of data elements. The number of data elements is the "execution size" or number of lanes of the instruction. An execution lane is an execution logic unit used for data element access, masking, and flow control within an instruction. The number of lanes may be independent of the number of physical arithmetic logic units (ALUs) or floating point units (FPUs) of a particular graphics processor. In some examples, the execution units 3008A-3008N support integer and floating point data types.

[0322] The execution unit instruction set includes SIMD instructions. Various data elements can be stored in registers as compact data types, and the execution unit will process various elements based on the data size of the element. For example, when operating a 256-bit wide vector, 256 bits of the vector are stored in registers, and the execution unit operates the vector as four separate 64-bit compact data elements (quadword (QW) size data elements), eight separate 32-bit compact data elements (doubleword (DW) size data elements), sixteen separate 16-bit compact data elements (word (W) size data elements) or thirty-two separate 8-bit data elements (byte (B) size data elements). However, different vector widths and register sizes are possible.

[0323] In some examples, one or more execution units may be combined into fused execution units 3009A-3009N having thread control logic (3007A-3007N) common to fused EUs. Multiple EUs may be fused into EU groups. Each EU in a fused EU group may be configured to execute a separate SIMD hardware thread. The number of EUs in a fused EU group may vary according to the example. In addition, each EU may execute various SIMD widths, including but not limited to SIMD8, SIMD16, and SIMD32. Each fused graphics execution unit 3009A-3009N includes at least two execution units. For example, a fused execution unit 3009A includes a first EU 3008A, a second EU 3008B, and a thread control logic 3007A common to the first EU 3008A and the second EU 3008B. The thread control logic 3007A controls the threads executed on the fused graphics execution unit 3009A, thereby allowing each EU within the fused execution unit 3009A-3009N to execute using a common instruction pointer register.

[0324] One or more internal instruction caches (e.g., 3006) are included in the thread execution logic 3000 to cache thread instructions for the execution unit. In some examples, one or more data caches (e.g., 3012) are included to cache thread data during thread execution. Threads executing on the execution logic 3000 may also store explicitly managed data in the shared local memory 3011. In some examples, a sampler 3010 is included to provide texture sampling for 3D operations and media sampling for media operations. In some examples, the sampler 3010 includes a dedicated texture or media sampling function to process the texture or media data during the sampling process before providing the sampled data to the execution unit.

[0325] During execution, the graphics and media pipeline sends a thread initiation request to the thread execution logic 3000 via the thread derivation and dispatch logic. Once a set of geometric objects has been processed and rasterized into pixel data, the pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) within the shader processor 3002 is called to further calculate output information and cause the result to be written to the output surface (e.g., color buffer, depth buffer, template buffer, etc.). In some examples, the pixel shader or fragment shader calculates the values ​​of various vertex attributes that will be interpolated across the rasterized object. In some examples, the pixel processor logic within the shader processor 3002 then executes the pixel or fragment shader program supplied by the application programming interface (API). In order to execute the shader program, the shader processor 3002 dispatches the thread to the execution unit (e.g., 3008A) via the thread dispatcher 3004. In some examples, the shader processor 3002 uses the texture sampling logic in the sampler 3010 to access the texture data in the texture map stored in the memory. Arithmetic operations on texture data and input geometry data compute pixel color data for each geometry fragment, or discard one or more pixels from further processing.

[0326] In some examples, data port 3014 provides a memory access mechanism for thread execution logic 3000 to output processed data to memory for further processing on a graphics processor output pipeline. In some examples, data port 3014 includes or is coupled to one or more cache memories (e.g., data cache 3012) to cache data for memory access via the data port.

[0327] In some examples, the execution logic 3000 may also include a ray tracer 3005 that may provide ray tracing acceleration functionality. The ray tracer 3005 may support a ray tracing instruction set that includes instructions / functions for ray generation.

[0328] Fig. 30BExemplary internal details of an execution unit 3008 according to an example are illustrated. Graphics execution unit 3008 may include an instruction fetch unit 3037, a general register file array (GRF) 3024, an architectural register file array (ARF) 3026, a thread arbiter 3022, an issue unit 3030, a branch unit 3032, a set of SIMD floating point units (FPUs) 3034, and in some examples, a set of dedicated integer SIMD ALUs 3035. GRF 3024 and ARF 3026 include a set of general register files and architectural register files associated with various simultaneous hardware threads that may be active in graphics execution unit 3008. In some examples, a per-thread architectural state is maintained in ARF 3026, while data used during thread execution is stored in GRF 3024. The execution state of each thread, including the instruction pointer of each thread, may be maintained in thread-specific registers in ARF 3026.

[0329] In some examples, the graphics execution unit 3008 has an architecture that is a combination of simultaneous multithreading (SMT) and fine-grained interleaved multithreading (IMT). The architecture has a modular configuration that can be fine-tuned at design time based on the target number of simultaneous threads and the number of registers per execution unit, where execution unit resources are divided across logic for executing multiple simultaneous threads. The number of logical threads that the graphics execution unit 3008 can execute is not limited to the number of hardware threads, and multiple logical threads can be assigned to individual hardware threads.

[0330] In some examples, the graphics execution unit 3008 may issue multiple instructions together, each of which may be a different instruction. The thread arbiter 3022 of the graphics execution unit thread 3008 may dispatch the instruction to one of the send unit 3030, the branch unit 3032, or the SIMD FPU 3034 for execution. Each execution thread may access 128 general registers within the GRF 3024, wherein each register may store 32 bytes and may be accessed as a SIMD 8 element vector of a 32-bit data element. In some examples, each execution unit thread may access 4K bytes within the GRF 3024, but the example is not limited thereto, and more or less register resources may be provided in other examples. In some examples, the graphics execution unit 3008 is divided into seven hardware threads that may independently perform computing operations, but the number of threads of each execution unit may also vary according to the example. For example, in some examples, up to 16 hardware threads are supported. In an example where seven threads may access 4K bytes, the GRF 3024 may store a total of 28K bytes. With 16 threads able to access 4K bytes, the GRF3024 can store a total of 64K bytes. Flexible addressing modes can allow registers to be addressed together to efficiently build wider registers or rectangular blocks representing strided data structures.

[0331] In some examples, memory operations, sampler operations, and other longer latency system communications are dispatched via "send" instructions executed by the message passing send unit 3030. In some examples, branch instructions are dispatched to a dedicated branch unit 3032 to facilitate SIMD divergence and eventual convergence.

[0332] In some examples, the graphics execution unit 3008 includes one or more SIMD floating point units 3034 that perform floating point operations. In some examples, the FPU 3034 also supports integer calculations. In some examples, the FPU 3034 can SIMD perform up to M 32-bit floating point (or integer) operations, or SIMD perform up to 2M 16-bit integer or 16-bit floating point operations. In some examples, at least one of the FPUs provides extended math capabilities to support high throughput transcendental math functions and double precision 64-bit floating point. In some examples, there is also a set of 8-bit integer SIMD ALUs 3035, and they can be specifically optimized to perform operations associated with machine learning calculations.

[0333] In some examples, an array of multiple instances of graphics execution unit 3008 can be instantiated in graphics sub-core groupings (e.g., sub-slices). For scalability, product designers can choose the exact number of execution units per sub-core grouping. In some examples, execution unit 3008 can execute instructions across multiple execution lanes. In other examples, individual threads executing on graphics execution unit 3008 execute on different lanes.

[0334] Fig.31 An additional execution unit 3100 according to an example is illustrated. In some examples, the execution unit 3100 includes a thread control unit 3101, a thread state unit 3102, an instruction fetch / prefetch unit 3103, and an instruction decode unit 3104. The execution unit 3100 further includes a register file 3106, which stores registers that can be assigned to hardware threads within the execution unit. The execution unit 3100 further includes a dispatch unit 3107 and a branch unit 3108. In some examples, the dispatch unit 3107 and the branch unit 3108 can be connected to Fig. 30B The sending unit 3030 and the branching unit 3032 of the graphics execution unit 3008 operate similarly.

[0335] The execution unit 3100 also includes a computing unit 3110, which includes a plurality of different types of functional units. In some examples, the computing unit 3110 includes an ALU unit 3111, which includes an array of arithmetic logic units. The ALU unit 3111 may be configured to perform 64-bit, 32-bit, and 16-bit integer and floating-point operations. Integer and floating-point operations may be performed simultaneously. The computing unit 3110 may also include a systolic array 3112 and a mathematical unit 3113. The systolic array 3112 includes a W-wide and D-deep network of data processing units, which may be used to perform vector or other data parallel operations in a systolic manner. In some examples, the systolic array 3112 may be configured to perform matrix operations, such as matrix dot product operations. In some examples, the systolic array 3112 supports 16-bit floating-point operations and 8-bit and 4-bit integer operations. In some examples, the systolic array 3112 may be configured to accelerate machine learning operations. In such an example, the systolic array 3112 may be configured to support the bfloat 16-bit floating-point format. In some examples, math unit 3113 may be included to perform a specific subset of math operations in an efficient and low power manner compared to ALU unit 3111. Math unit 3113 may include a variation of math logic that may be used in the shared functional logic of the graphics processing engine provided by other examples (e.g., Figure 4 In some examples, math unit 3113 may be configured to perform 32-bit and 64-bit floating point operations.

[0336] The thread control unit 3101 includes logic for controlling the execution of threads within the execution unit. The thread control unit 3101 may include thread arbitration logic that starts, stops, and preempts the execution of threads within the execution unit 3100. The thread state unit 3102 may be used to store the thread states of threads assigned to execute on the execution unit 3100. Storing thread states within the execution unit 3100 enables fast preemption of threads when they become blocked or idle. The instruction fetch / prefetch unit 3103 may fetch instructions from the instruction cache of higher-level execution logic (e.g., Fig. 30A The instruction fetch / prefetch unit 3103 may also issue a prefetch request for instructions to be loaded into the instruction cache based on an analysis of the currently executing thread. The instruction decode unit 3104 may be used to decode instructions to be executed by the computing unit. In some examples, the instruction decode unit 3104 may be used as an auxiliary decoder to decode complex instructions into constituent micro-operations.

[0337] The execution unit 3100 further includes a register file 3106 that can be used by hardware threads executing on the execution unit 3100. The registers in the register file 3106 can be divided across logic for executing multiple simultaneous threads within the compute unit 3110 of the execution unit 3100. The number of logical threads that the graphics execution unit 3100 can execute is not limited to the number of hardware threads, and multiple logical threads can be assigned to individual hardware threads. The size of the register file 3106 can vary across examples based on the number of hardware threads supported. In some examples, register renaming can be used to dynamically assign registers to hardware threads.

[0338] Fig.32 3200 is a block diagram illustrating a graphics processor instruction format 3200 according to some examples. In one or more examples, a graphics processor execution unit supports an instruction set having instructions in multiple formats. Solid line boxes illustrate components that are typically included in execution unit instructions, while dashed lines include components that are optional or included only in a subset of instructions. In some examples, the described and illustrated instruction format 3200 are macroinstructions in that they are instructions provided to the execution unit, as opposed to micro-operations that are generated by instruction decoding once the instruction is processed.

[0339] In some examples, the graphics processor execution unit natively supports instructions in 128-bit instruction format 3210. Based on the selected instruction, instruction options, and the number of operands, 64-bit compressed instruction format 3230 can be used for certain instructions. Native 128-bit instruction format 3210 provides access to all instruction options, while some options and operations are restricted in 64-bit format 3230. The native instructions available in 64-bit format 3230 vary from example to example. In some examples, instructions are partially compressed using a set of index values ​​in index field 3213. The execution unit hardware references a set of compression tables based on the index values, and uses the compression table output to reconstruct the native instructions of 128-bit instruction format 3210. Instructions of other sizes and formats can be used.

[0340] For various formats, the instruction opcode 3212 defines the operation to be performed by the execution unit. The execution unit executes each instruction in parallel across multiple data elements of each operand. For example, in response to an addition instruction, the execution unit performs simultaneous addition operations across each color channel representing a texture element or a picture element. By default, the execution unit executes each instruction across all data channels of the operand. In some examples, the instruction control field 3214 enables control of certain execution options, such as channel selection (e.g., predicate) and data channel order (e.g., swizzle). For instructions of the 128-bit instruction format 3210, the execution size field 3216 limits the number of data channels that will be executed in parallel. In some examples, the execution size field 3216 is not available for the 64-bit compact instruction format 3230.

[0341] Some execution unit instructions have up to three operands, including two source operands src0 3220, src1 3222 and one destination 3218. In some examples, the execution unit supports dual destination instructions, where one of the destinations is implicit. Data manipulation instructions may have a third source operand (e.g., SRC2 3224), where the instruction opcode 3212 determines the number of source operands. The last source operand of an instruction may be an immediate (e.g., hard-coded) value passed with the instruction.

[0342] In some examples, the 128-bit instruction format 3210 includes an access / address mode field 3226 that specifies, for example, whether direct register addressing mode or indirect register addressing mode is used. When direct register addressing mode is used, the register address of one or more operands is provided directly by bits in the instruction.

[0343] In some examples, the 128-bit instruction format 3210 includes an access / address mode field 3226 that specifies an address mode and / or access mode for the instruction. In some examples, the access mode is used to define the data access alignment of the instruction. Some examples support access modes including a 16-byte aligned access mode and a 1-byte aligned access mode, wherein the byte alignment of the access mode determines the access alignment of the instruction operand. For example, when in a first mode, the instruction can use byte-aligned addressing for source operands and destination operands, and when in a second mode, the instruction can use 16-byte aligned addressing for all source operands and destination operands.

[0344] In some examples, the address mode portion of the access / address mode field 3226 determines whether the instruction is to use direct or indirect addressing. When direct register addressing mode is used, the bits in the instruction directly provide the register address of one or more operands. When indirect register addressing mode is used, the register address of one or more operands can be calculated based on the address register value and the address immediate field in the instruction.

[0345] In some examples, instructions are grouped based on the opcode 3212 bit field to simplify opcode decoding 3240. For 8-bit opcodes, bits 4, 5, and 6 allow the execution unit to determine the type of opcode. The precise opcode grouping shown is only an example. In some examples, the move and logic opcode group 3242 includes data movement and logic instructions (e.g., move (mov), compare (cmp)). In some examples, the move and logic group 3242 shares five most significant bits (MSBs), wherein the move (mov) instruction takes the form of 0000xxxxb, and the logic instruction takes the form of 0001xxxxb. The flow control instruction group 3244 (e.g., call, jump (jmp)) includes instructions in the form of 0010xxxxb (e.g., 0x20). The miscellaneous instruction group 3246 includes a mixture of instructions, including synchronization instructions (e.g., wait, send) in the form of 0011xxxxb (e.g., 0x30). The parallel math instruction group 3248 includes component-wise arithmetic instructions (e.g., addition, multiplication (mul)) of the form 0100xxxxb (e.g., 0x40). The parallel math group 3248 performs arithmetic operations in parallel across data channels. The vector math group 3250 includes arithmetic instructions (e.g., dp4) of the form 0101xxxxb (e.g., 0x50). The vector math group performs operations such as dot product calculations on vector operands. In some examples, the illustrated opcode decode 3240 can be used to determine which portion of the execution unit will be used to execute the decoded instructions. For example, some instructions may be designated as systolic instructions to be executed by a systolic array. Other instructions such as ray tracing instructions (not shown) can be routed to a ray tracing core or ray tracing logic within a slice or partition of the execution logic.

[0346] Graphics Pipeline

[0347] Fig.33 is a block diagram of another example of a graphics processor 3300 . Fig.33 Elements in the drawings having the same reference numbers (or names) as elements of any other figures herein may operate or function in any manner similar to that described elsewhere herein, but are not limited thereto.

[0348] In some examples, graphics processor 3300 includes a geometry pipeline 3320, a media pipeline 3330, a display engine 3340, a thread execution logic 3350, and a rendering output pipeline 3370. In some examples, graphics processor 3300 is a graphics processor within a multi-core processing system that includes one or more general-purpose processing cores. The graphics processor is controlled by register writes to one or more control registers (not shown) or via commands issued to graphics processor 3300 through ring interconnect 3302. In some examples, ring interconnect 3302 couples graphics processor 3300 to other processing components, such as other graphics processors or general-purpose processors. Commands from ring interconnect 3302 are interpreted by command stream converter 3303, which provides instructions to various components of geometry pipeline 3320 or media pipeline 3330.

[0349] In some examples, command stream converter 3303 directs the operation of vertex fetcher 3305, which reads vertex data from memory and executes vertex processing commands provided by command stream converter 3303. In some examples, vertex fetcher 3305 provides vertex data to vertex shader 3307, which performs coordinate space transformation and lighting operations on individual vertices. In some examples, vertex fetcher 3305 and vertex shader 3307 execute vertex processing instructions by dispatching execution threads to execution units 3352A-3352B via thread dispatcher 3331.

[0350] In some examples, execution units 3352A-3352B are vector processor arrays with instruction sets for performing graphics and media operations. In some examples, execution units 3352A-3352B have an additional L1 cache 3351 that is specific to each array or shared between arrays. The cache can be configured as a data cache, an instruction cache, or a single cache that is partitioned to contain data and instructions in different partitions.

[0351] In some examples, the geometry pipeline 3320 includes a tessellation component that performs hardware accelerated tessellation of 3D objects. In some examples, the programmable shell shader 3311 configures the tessellation operation. The programmable domain shader 3317 provides back-end evaluation of the tessellation output. The tessellation 3313 operates under the direction of the shell shader 3311 and contains dedicated logic that generates a set of detailed geometric objects based on the rough geometric model provided as input to the geometry pipeline 3320. In some examples, if tessellation is not used, the tessellation components (e.g., the shell shader 3311, the tessellation 3313, and the domain shader 3317) can be bypassed.

[0352] In some examples, geometry shader 3319 may process complete geometric objects via one or more threads dispatched to execution units 3352A-3352B, or may proceed directly to clipper 3329. In some examples, the geometry shader operates on entire geometric objects, rather than on vertices or vertex patches as in previous stages of the graphics pipeline. If tessellation is disabled, geometry shader 3319 receives input from vertex shader 3307. In some examples, geometry shader 3319 may be programmed by a geometry shader program to perform geometry tessellation when the tessellation unit is disabled.

[0353] Before rasterization, the clipper 3329 processes the vertex data. The clipper 3329 can be a fixed function clipper or a programmable clipper with clipping and geometry shader functions. In some examples, the rasterizer and depth test component 3373 in the rendering output pipeline 3370 dispatches a pixel shader to convert the geometric object into a per-pixel representation. In some examples, the pixel shader logic is included in the thread execution logic 3350. In some examples, the application can bypass the rasterizer and depth test component 3373 and access the unrasterized vertex data via the outflow unit 3323.

[0354] Graphics processor 3300 has an interconnect bus, interconnect structure, or some other interconnect mechanism that allows data and messages to be passed between the main components of the processor. In some examples, execution units 3352A-3352B and associated logic units (e.g., L1 cache 3351, sampler 3354, texture cache 3358, etc.) are interconnected via data port 3356 to perform memory access and communicate with the rendering output pipeline components of the processor. In some examples, sampler 3354, cache 3351, 3358, and execution units 3352A-3352B each have a separate memory access path. In some examples, texture cache 3358 can also be configured as a sampler cache.

[0355] In some examples, the render output pipeline 3370 includes a rasterizer and depth test component 3373 that converts vertex-based objects into associated pixel-based representations. In some examples, the rasterizer logic includes a windower / masker unit that performs fixed-function triangle and line rasterization. In some examples, an associated render cache 3378 and depth cache 3379 are also available. A pixel operation component 3377 performs pixel-based operations on data, but in some cases, pixel operations associated with 2D operations (e.g., bit-block image transfers with blending) are performed by the 2D engine 3341, or replaced by a display controller 3343 using an overlay display plane when displaying. In some examples, a shared L3 cache 3375 is available to all graphics components, allowing data to be shared without using main system memory.

[0356] In some examples, the graphics processor media pipeline 3330 includes a media engine 3337 and a video front end 3334. In some examples, the video front end 3334 receives pipeline commands from the command stream converter 3303. In some examples, the media pipeline 3330 includes a separate command stream converter. In some examples, the video front end 3334 processes the media commands before sending them to the media engine 3337. In some examples, the media engine 3337 includes a thread spawning function that spawns threads for dispatching to the thread execution logic 3350 via the thread dispatcher 3331.

[0357] In some examples, graphics processor 3300 includes display engine 3340. In some examples, display engine 3340 is external to processor 3300 and is coupled to the graphics processor via ring interconnect 3302 or some other interconnect bus or structure. In some examples, display engine 3340 includes 2D engine 3341 and display controller 3343. In some examples, display engine 3340 includes dedicated logic that can operate independently of the 3D pipeline. In some examples, display controller 3343 is coupled to a display device (not shown), which can be a system integrated display device such as in a laptop computer, or an external display device attached via a display device connector.

[0358] In some examples, geometry pipeline 3320 and media pipeline 3330 may be configured to perform operations based on multiple graphics and media programming interfaces, and are not specific to any one application programming interface (API). In some examples, driver software for a graphics processor translates API calls specific to a specific graphics or media library into commands that can be processed by a graphics processor. In some examples, support is provided for Open Graphics Library (OpenGL), Open Computing Language (OpenCL) and / or Vulkan graphics and computing APIs, all of which are from the Khronos organization. In some examples, support for Direct3D libraries from Microsoft Corporation may also be provided. In some examples, combinations of these libraries may be supported. Support for open source computer vision libraries (OpenCV) may also be provided. If a mapping from a pipeline of a future API to a pipeline of a graphics processor can be performed, future APIs with compatible 3D pipelines will also be supported.

[0359] Graphics Pipeline Programming

[0360] Fig.34A is a block diagram illustrating a graphics processor command format 3400 according to some examples. Fig.34B is a block diagram illustrating a graphics processor command sequence 3410 according to an example. Fig.34A The solid-line boxes in exemplify components that are typically included in a graphics command, while the dashed lines include components that are optional or included only in a subset of the graphics commands. Fig.34A The exemplary graphics processor command format 3400 includes a data field identifying the client 3402, a command operation code (opcode) 3404, and command data 3406. Some commands also include a sub-opcode 3405 and a command size 3408.

[0361] In some examples, client 3402 specifies a client unit of a graphics device that processes command data. In some examples, a graphics processor command parser examines the client field of each command to adjust further processing of the command and routes the command data to the appropriate client unit. In some examples, the graphics processor client unit includes a memory interface unit, a rendering unit, a 2D unit, a 3D unit, and a media unit. Each client unit has a corresponding processing pipeline for processing commands. Once the client unit receives the command, the client unit reads the opcode 3404 and, if present, reads the sub-opcode 3405 to determine the operation to be performed. The client unit executes the command using the information in the data field 3406. For some commands, it is expected that an explicit command size 3408 specifies the size of the command. In some examples, the command parser automatically determines the size of at least some commands based on the command opcode. In some examples, commands are aligned via multiples of double words. Other command formats may be used.

[0362] Fig.34B The flowchart in 3410 illustrates an exemplary graphics processor command sequence 3410. In some examples, software or firmware of a data processing system featuring an example of a graphics processor uses a version of the command sequence shown to set up, execute, and terminate a set of graphics operations. The example command sequence is shown and described for example purposes only, as the examples are not limited to these particular commands or to the command sequence. Moreover, the commands can be issued as batch commands in a command sequence so that the graphics processor will process the command sequence at least partially concurrently.

[0363] In some examples, the graphics processor command sequence 3410 may begin with a pipeline flush command 3412 to cause any active graphics pipeline to complete currently pending commands for the pipeline. In some examples, the 3D pipeline 3422 and the media pipeline 3424 do not operate concurrently. The pipeline flush is performed to cause the active graphics pipeline to complete any pending commands. In response to the pipeline flush, the command parser of the graphics processor will suspend command processing until the active drawing engine completes pending operations and the associated read cache is invalidated. Optionally, any data marked as "dirty" in the render cache may be flushed to memory. In some examples, the pipeline flush command 3412 may be used for pipeline synchronization or before placing the graphics processor in a low power state.

[0364] In some examples, pipeline select command 3413 is used when a command sequence requires the graphics processor to explicitly switch between pipelines. In some examples, pipeline select command 3413 is only required once within an execution context before issuing pipeline commands unless the context is to issue commands for both pipelines. In some examples, pipeline flush command 3412 is required immediately before pipelines are switched via pipeline select command 3413.

[0365] In some examples, pipeline control commands 3414 configure the graphics pipeline for operation and are used to program 3D pipeline 3422 and media pipeline 3424. In some examples, pipeline control commands 3414 configure the pipeline state of the active pipeline. In some examples, pipeline control commands 3414 are used for pipeline synchronization and to clear data from one or more cache memories within the active pipeline before processing a batch of commands.

[0366] In some examples, return buffer state command 3416 is used to configure a set of return buffers for a corresponding pipeline to write data. Some pipeline operations require allocating, selecting, or configuring one or more return buffers, and during processing, the operation writes intermediate data to the return buffers. In some examples, the graphics processor also uses one or more return buffers to store output data and perform cross-thread communication. In some examples, return buffer state 3416 includes selecting the size and number of return buffers to use for a set of pipeline operations.

[0367] The remaining commands in the command sequence differ based on the active pipeline for operation.Based on pipeline determination 3420 , the command sequence is tailored to either 3D pipeline 3422 starting with 3D pipeline state 3430 or media pipeline 3424 starting with media pipeline state 3440 .

[0368] The commands to configure the 3D pipeline state 3430 include 3D state setting commands for vertex buffer state, vertex element state, constant color state, depth buffer state, and other state variables to be configured before processing 3D primitive commands. The values ​​of these commands are determined at least in part based on the specific 3D API used. In some examples, the 3D pipeline state 3430 commands can also selectively disable or bypass certain pipeline elements if these elements will not be used.

[0369] In some examples, the 3D primitive 3432 command is used to submit the 3D primitive for processing by the 3D pipeline. The command and associated parameters passed to the graphics processor via the 3D primitive 3432 command are forwarded to the vertex acquisition function in the graphics pipeline. The vertex acquisition function uses the 3D primitive 3432 command data to generate a vertex data structure. The vertex data structure is stored in one or more return buffers. In some examples, the 3D primitive 3432 command is used to perform vertex operations on the 3D primitive via a vertex shader. In order to process the vertex shader, the 3D pipeline 3422 dispatches the shader execution thread to the graphics processor execution unit.

[0370] In some examples, the 3D pipeline 3422 is triggered via an execute 3434 command or event. In some examples, a register write triggers command execution. In some examples, execution is triggered via a "go" or "kick" command in a command sequence. In some examples, command execution is triggered using a pipeline synchronization command to flush the command sequence through the graphics pipeline. The 3D pipeline will perform geometry processing of the 3D primitives. Once the operation is completed, the resulting geometric objects are rasterized and the pixel engine colors the resulting pixels. For these operations, additional commands for controlling pixel shading and pixel backend operations may also be included.

[0371] In some examples, when performing media operations, the graphics processor command sequence 3410 follows the media pipeline 3424 path. In general, the specific use and manner of programming for the media pipeline 3424 depends on the media or computing operations to be performed. Specific media decoding operations can be offloaded to the media pipeline during media decoding. In some examples, the media pipeline can also be bypassed, and the media decoding can be performed in whole or in part using resources provided by one or more general-purpose processing cores. In some examples, the media pipeline also includes elements for general-purpose graphics processor unit (GPGPU) operations, wherein the graphics processor is used to perform SIMD vector operations using compute shader programs that are not explicitly related to the rendering of graphics primitives.

[0372] In some examples, media pipeline 3424 is configured in a similar manner to 3D pipeline 3422. A set of commands that configure media pipeline state 3440 are dispatched or placed into a command queue before media object commands 3442. In some examples, commands for media pipeline state 3440 include data that configures media pipeline elements that will be used to process media objects. This includes data that configures video decoding and video encoding logic within the media pipeline, such as encoding or decoding formats. In some examples, commands for media pipeline state 3440 also support the use of one or more pointers to "indirect" state elements that contain a batch of state settings.

[0373] In some examples, media object command 3442 provides a pointer to a media object for processing by the media pipeline. The media object includes a memory buffer containing video data to be processed. In some examples, all media pipeline states must be valid before issuing media object command 3442. Once the pipeline states are configured and media object command 3442 is queued, media pipeline 3424 is triggered via execute command 3444 or an equivalent execution event (e.g., a register write). The output from media pipeline 3424 can then be post-processed by operations provided by 3D pipeline 3422 or media pipeline 3424. In some examples, GPGPU operations are configured and executed in a manner similar to media operations.

[0374] Program code can be applied to input information to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system with a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microprocessor, or any combination thereof.

[0375] The program code can be implemented with a high-level program or object-oriented programming language to communicate with the processing system. If desired, the program code can also be implemented in assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled or interpreted language.

[0376] Examples of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementation methods. Examples may be implemented as a computer program or program code executed on a programmable system, the programmable system comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0377] Such machine-readable storage media may include, but are not limited to, a non-transitory tangible arrangement of an article manufactured or formed by a machine or device, including storage media such as a hard disk, any other type of disk, including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks; semiconductor devices such as read-only memory (ROM), random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase change memory (PCM), magnetic or optical cards, or any other type of medium suitable for storing electronic instructions.

[0378] Therefore, examples also include non-transitory tangible machine-readable media containing instructions or containing design data, such as hardware description language (HDL), which defines the structures, circuits, devices, processors and / or system features described herein. Such examples may also be referred to as program products.

[0379] Simulation (including binary translation, code deformation, etc.).

[0380] In some cases, the instruction converter can be used to convert instructions from a source instruction set architecture to a target instruction set architecture. For example, the instruction converter can translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter can be implemented in software, hardware, firmware or a combination thereof. The instruction converter can be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0381] Fig.351 is a block diagram illustrating the use of a software instruction converter to convert binary instructions in a source ISA into binary instructions in a target ISA according to an example. In the illustrated example, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.35 It is shown that a program in a high-level language 3502 can be compiled using a first ISA compiler 3504 to generate first ISA binary code 3506 that can be natively executed by a processor having at least one first ISA core 3516. A processor having at least one first ISA core 3516 represents any processor that can execute programs with an Intel processor having at least one first ISA core in the following manner: Processor substantially the same functionality: compatibly execute or otherwise process (1) a substantial portion of the first ISA or (2) an object code version of an application or other software targeted to run on an Intel processor having at least one first ISA core so as to achieve substantially the same results as a processor having at least one first ISA core. First ISA compiler 3504 represents a compiler operable to generate first ISA binary code 3506 (e.g., object code) that can be executed on a processor having at least one first ISA core 3516 with or without additional link processing. Similarly, Fig.35 It is shown that a program of a high-level language 3502 can be compiled using an alternative ISA compiler 3508 to generate an alternative ISA binary code 3510 that can be natively executed by a processor without a first ISA core 3514. An instruction converter 3512 is used to convert the first ISA binary code 3506 into a code that can be natively executed by a processor without a first ISA core 3514. The converted code does not have to be the same as the ISA binary code 3510 replaced; however, the converted code will complete general operations and consist of instructions from the replacement ISA. Thus, the instruction converter 3512 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without a first ISA processor or core to execute the first ISA binary code 3506 by simulation, emulation, or any other process.

[0382] IP Core Implementation

[0383] One or more aspects of at least some examples may be implemented by representative code stored on a machine-readable medium, which represents and / or defines logic within an integrated circuit such as a processor. For example, a machine-readable medium may include instructions representing various logic within a processor. When read by a machine, the instructions may cause the machine to manufacture logic to perform the techniques described herein. This representation (referred to as an "IP core") is a reusable logic unit for an integrated circuit that may be stored on a tangible machine-readable medium as a hardware model describing the structure of the integrated circuit. The hardware model may be provided to various customers or manufacturing facilities, which load the hardware model onto a manufacturing machine that manufactures the integrated circuit. The integrated circuit may be manufactured so that the circuit performs the operations described in association with any of the examples described herein.

[0384] Fig.36 36 is a block diagram illustrating an IP core development system 3600 that can be used to manufacture an integrated circuit to perform operations according to some examples. The IP core development system 3600 can be used to generate modular, reusable designs that can be incorporated into a larger design or used to construct an entire integrated circuit (e.g., a SOC integrated circuit). The design facility 3630 can generate a software simulation 3610 of the IP core design in a high-level programming language (e.g., C / C++). The software simulation 3610 can be used to design, test, and verify the behavior of the IP core using a simulation model 3612. The simulation model 3612 may include functional, behavioral, and / or timing simulations. Then, a register transfer level (RTL) design 3615 can be created or synthesized based on the simulation model 3612. The RTL design 3615 is an abstraction of the behavior of an integrated circuit (including associated logic executed using the modeled digital signals) that models the flow of digital signals between hardware registers. In addition to the RTL design 3615, a low-level design at the logic level or transistor level can also be created, designed, or synthesized. Thus, the specific details of the initial design and simulation can vary.

[0385] The RTL design 3615 or equivalent may be further synthesized by the design facility into a hardware model 3620, which may be a hardware description language (HDL) or some other representation of physical design data. The HDL may be further simulated or tested to verify the IP core design. Non-volatile memory 3640 (e.g., a hard disk, flash memory, or any non-volatile storage medium) may be used to store the IP core design for delivery to a third party manufacturing facility 3665. Alternatively, the IP core design may be transmitted (e.g., via the Internet) via a wired connection 3650 or a wireless connection 3660. The manufacturing facility 3665 may then manufacture an integrated circuit based at least in part on the IP core design. The manufactured integrated circuit may be configured to perform operations according to at least some of the examples described herein.

[0386] References to "some examples," "examples," etc. indicate that the examples described may include a particular feature, structure, or characteristic, but every example may not necessarily include the particular feature, structure, or characteristic. Moreover, these phrases do not necessarily refer to the same example. Further, when a particular feature, structure, or characteristic is described in conjunction with an example, it is considered to be within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other examples, whether or not explicitly described.

[0387] Examples include, but are not limited to:

[0388] 1. A device comprising:

[0389] A storage device storing 1600 bits of input state;

[0390] A Keccak round data path is coupled to the storage device, the Keccak round data path comprising at least:

[0391] The first path includes a θ step, a ρ step, a π step, and an ι step to process 1600

[0392] A masked version of the bit input state,

[0393] The second path includes a θ step, a ρ step, and a π step to process the masked 1600-bit input state, and

[0394] After the masking x step, it is shared by the first path and the second path.

[0395] 2. The apparatus of Example 1, wherein the Keccak round data path further comprises at least a storage device for a mask.

[0396] 3. The apparatus of example 2, wherein the mask is a random 1600-bit value.

[0397] 4. The apparatus of Example 2, wherein the Keccak round data path further comprises at least an XOR circuit that XORs the 1600-bit input state with a mask to generate a masked version of the 1600-bit input state.

[0398] 5. The apparatus according to any one of Examples 1 to 4, wherein the Keccak round data path further comprises at least an XOR circuit that XORs the outputs of the first path and the second path as an output state.

[0399] 6. The apparatus according to any one of Examples 1 to 5, further comprising:

[0400] A decoder circuit decodes a Keccak instruction, the Keccak instruction including at least one field identifying the location of a 1600-bit input state, at least one field identifying the location of a 1600-bit output state, and a field for an opcode, the opcode being used to indicate that the Keccak-round data path is to perform a Keccak-round calculation.

[0401] 7. The apparatus according to any one of Examples 1 to 5, further comprising:

[0402] A decoder circuit decodes a Keccak instruction, the Keccak instruction including at least one field identifying the location of a 1600-bit input state, at least one field identifying the location of a 1600-bit output state, and a field for an opcode, the opcode being used to indicate that the Keccak round data path is to perform a Keccak permutation.

[0403] 8. The apparatus of example 7, wherein the Keccak permutation comprises a Keccak round.

[0404] 9. An apparatus according to any one of Examples 1 to 8, wherein the second path including θ steps, ρ steps and π steps to process masked 1600-bit input states and the shared masked χ step is only used for a proper subset of the Keccak permutation round.

[0405] 10. The apparatus of any one of Examples 1 to 9, wherein the Keccak round data path is used serially for a plurality of Keccak rounds.

[0406] 11. A system comprising:

[0407] A memory that stores 1600 bits of input state;

[0408] An execution circuit comprising:

[0409] A Keccak round data path is coupled to the memory, the Keccak round data path comprising at least:

[0410] The first path, which includes the θ step, the ρ step, the π step, and the ι step, processes a masked version of the 1600-bit input state,

[0411] The second path includes a θ step, a ρ step, and a π step to process the masked 1600-bit input state, and

[0412] After the masking x step, it is shared by the first path and the second path; and

[0413] Other SHA3 circuits.

[0414] 12. The system of example 11, wherein the Keccak round data path further comprises at least a storage device for a mask.

[0415] 13. The system of example 12, wherein the mask is a random 1600-bit value.

[0416] 14. The system of example 12, wherein the Keccak round data path further comprises at least an XOR circuit that XORs the 1600-bit input state with a mask to generate a masked version of the 1600-bit input state.

[0417] 15. The system according to any one of Examples 11 to 14, wherein the Keccak round data path further comprises at least an XOR circuit that XORs the outputs of the first path and the second path as an output state.

[0418] 16. The system of any one of Examples 11 to 15, further comprising:

[0419] A decoder circuit decodes a Keccak instruction, the Keccak instruction including at least one field identifying the location of a 1600-bit input state, at least one field identifying the location of a 1600-bit output state, and a field for an opcode, the opcode being used to indicate that the Keccak-round data path is to perform a Keccak-round calculation.

[0420] 17. The system of any one of Examples 11 to 15, further comprising:

[0421] A decoder circuit decodes a Keccak instruction, the Keccak instruction including at least one field identifying the location of a 1600-bit input state, at least one field identifying the location of a 1600-bit output state, and a field for an opcode, the opcode being used to indicate that the Keccak round data path is to perform a Keccak permutation.

[0422] 18. The system of example 17, wherein the Keccak permutation comprises a Keccak round.

[0423] 19. The system of any one of examples 11 to 18, wherein the θ step, the ρ step, and the π step are shared by the first path and the second path.

[0424] 20. A method comprising:

[0425] Split the 1600-bit input state into two random 1600-bit states;

[0426] Perform linear Keccak operations independently on two 1600-bit random states;

[0427] combining the outputs of the linear Keccak operation on the two random states in a nonlinear χ-step calculation to produce an update value; and

[0428] Perform an ι operation on the output of the nonlinear χ calculation.

[0429] Moreover, in the various examples above, unless specifically noted otherwise, disjunctive language such as the phrases "at least one of A, B, or C" or "A, B and / or C" are intended to be understood to mean A, B, or C or any combination thereof (i.e., A and B, A and C, B and C, and A, B, and C).

[0430] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the claims.

Claims

1. A device comprising: A storage device for storing 1600 bits of input state; A Keccak round data path, the Keccak round data path is coupled to the storage device, the Keccak round data path comprising at least: a first path comprising a θ step, a ρ step, a π step, and an ι step to process a masked version of the 1600-bit input state; a second path, the second path comprising a θ step, a ρ step, and a π step to process a masked 1600-bit input state; and A masked x-step, the masked x-step being shared by the first path and the second path.

2. The device according to claim 1, wherein: The Keccak round data path further comprises at least: a storage device for a mask.

3. The device according to claim 2, wherein: The mask is a random 1600-bit value.

4. The device according to claim 2, wherein: The Keccak round data path also includes at least: an XOR circuit for XORing the 1600-bit input state with a mask to generate a masked version of the 1600-bit input state.

5. The device according to claim 1, wherein: The Keccak round data path also includes at least: an XOR circuit, used to perform XOR on the outputs of the first path and the second path as an output state.

6. The device according to any one of claims 1 to 5, further comprising: A decoder circuit is used to decode a Keccak instruction, wherein the Keccak instruction includes at least one field for identifying the position of the 1600-bit input state, at least one field for identifying the position of the 1600-bit output state, and a field for an opcode, wherein the opcode is used to indicate that the Keccak-round data path is to perform a Keccak-round calculation.

7. The device according to any one of claims 1 to 6, further comprising: A decoder circuit is used to decode a Keccak instruction, wherein the Keccak instruction includes at least one field for identifying the position of the 1600-bit input state, at least one field for identifying the position of the 1600-bit output state, and a field for an opcode, wherein the opcode is used to indicate that the Keccak round data path is to perform a Keccak permutation.

8. The device according to claim 7, wherein: The Keccak permutation includes a Keccak round.

9. The device according to any one of claims 1 to 8, wherein: The second path including θ steps, ρ steps, and π steps to process the masked 1600-bit input state and the shared masked χ steps is only used for a proper subset of the Keccak permutation round.

10. The device according to any one of claims 1 to 9, wherein: The Keccak round data path is used serially for multiple Keccak rounds.

11. A system comprising: Memory for storing 1600-bit input states; The execution circuit comprises: A Keccak round data path coupled to the memory, The Keccak round data path includes at least: a first path comprising a θ step, a ρ step, a π step, and an ι step to process a masked version of the 1600-bit input state; a second path, the second path comprising a θ step, a ρ step, and a π step, to process the masked 1600-bit input state; and a masked x-step, the masked x-step being shared by the first path and the second path; and Other SHA3 circuits.

12. The system according to claim 11, wherein: The Keccak round data path further comprises at least: a storage device for a mask.

13. The system according to claim 12, wherein: The mask is a random 1600-bit value.

14. The system according to claim 12, wherein: The Keccak round data path also includes at least: an XOR circuit for XORing the 1600-bit input state with a mask to generate a masked version of the 1600-bit input state.

15. The system according to claim 11, wherein: The Keccak round data path also includes at least: an XOR circuit, used to perform XOR on the outputs of the first path and the second path as an output state.

16. The system of claim 11, further comprising: A decoder circuit is used to decode a Keccak instruction, wherein the Keccak instruction includes at least one field for identifying the position of the 1600-bit input state, at least one field for identifying the position of the 1600-bit output state, and a field for an opcode, wherein the opcode is used to indicate that the Keccak-round data path is to perform a Keccak-round calculation.

17. The system of claim 11, further comprising: A decoder circuit is used to decode a Keccak instruction, wherein the Keccak instruction includes at least one field for identifying the position of the 1600-bit input state, at least one field for identifying the position of the 1600-bit output state, and a field for an opcode, wherein the opcode is used to indicate that the Keccak round data path is to perform a Keccak permutation.

18. The system of claim 17, wherein: The θ step, the ρ step, and the π step of the first path and the θ step, the ρ step, and the π step of the second path are not shared by the first path and the second path.

19. The system of claim 11, wherein: The θ step, the ρ step, and the π step are shared by the first path and the second path.

20. A method comprising: Split the 1600-bit input state into two random 1600-bit states; independently performing a linear Keccak operation on the two 1600-bit random states; combining the outputs of the linear Keccak operation on the two random states in a nonlinear x-step calculation to produce an update value; as well as An ι operation is performed on the output of the nonlinear χ calculation.

Images