DE102018123761A1 - FUSE PROTECTION IN AN ERROR CORRECTION CODE (ECC) IMPLEMENTED IN A MOTOR VEHICLE SYSTEM - Google Patents

Abstract

In general, data is susceptible to faults caused by hardware failures (i.e., permanent faults), such as faults. B. disturbances in the function of memory and / or communication channels. In order to detect errors in data caused by hardware interference, the Error Correction Code (ECC) has been introduced which essentially provides the data with some kind of redundancy that can be used to verify that the data is free from errors caused by hardware errors. In some cases, the ECC may also be used to correct errors caused by hardware failure in the data. However, the ECC itself is also prone to errors, especially errors caused by disturbances in the ECC logic. Thus, a method, a computer-readable medium, and an error-proofing system in an ECC are provided.

Description

Field of the invention

The present invention relates to codes used to control data errors, and more particularly to error correction code (ECC) logic used to control data errors.

background

In general, data is susceptible to faults caused by hardware failures (i.e., permanent faults), such as faults. B. disturbances in the function of memory and / or communication channels. In order to detect errors in data caused by hardware faults, codes have been developed which provide the data with a kind of redundancy. In some cases, these codes can even be used to correct the error in the data.

One design of a code that has been developed to detect and in some cases correct data errors caused by hardware interference is the Error Correcting Code (ECC). The ECC is generally logic that includes an encoder to encode a copy of the data to form a code, the code being transmitted and / or stored in association with the data. The ECC logic further includes a decoder for decoding the code so that the once decoded code can then be used to detect and optionally correct errors in the data. Unfortunately, ECC logic is also prone to errors that can introduce errors into the code itself. For example, disturbances in the encoder and / or decoder, such. For example, single stall events where a gate of the encoder / decoder is stuck at a certain value introduce errors into the code. Errors in the code can lead to false detection of errors in the data and, worse, incorrect correction of the data, which introduces more errors into the data.

So far, the ECC design has not been adapted to guard against errors introduced by the ECC logic itself. There is therefore a need to address these tasks and / or other tasks associated with the prior art.

Summary

Disclosed is a method, a computer-readable medium, and an error-proofing system in an ECC. In use, a code generated for data using error correction code (ECC) logic is accessed, the code being stored in a first memory and the data stored in a second memory. In addition, an error in the code caused by an error in the ECC logic is detected. Furthermore, it is determined whether the error in the code is correctable. In response to determining that the error in the code is correctable, the error in the code is corrected to form a corrected code, the data is retrieved from the second memory, and the retrieved data is verified using the corrected code. In response to determining that the error in the code is uncorrectable, the error in the code is displayed as being uncorrectable.

list of figures

• 1A FIG. 12 illustrates a flowchart of a method for securing against errors in an ECC according to one embodiment.
• 1B FIG. 12 illustrates a block diagram of an ECC logic architecture according to an embodiment. FIG.
• 1C illustrates a block diagram of the input and output of the ECC encoder of 1B according to one embodiment.
• 1D FIG. 12 illustrates a block diagram of the input and output of the ECC decoder of FIG 1B according to one embodiment.
• 2A-E illustrate a parity check matrix of a SEC-DED ECC logic design in conjunction with an ECC logic algorithm design for securing against errors in the ECC according to one embodiment.
• 3 illustrates a parallel processing unit according to an embodiment.
• 4A illustrates a general processing cluster within the parallel processing unit of FIG 3 according to one embodiment.
• 4B FIG. 10 illustrates a memory partition unit of the parallel processing unit of FIG 3 according to one embodiment.
• 5A illustrates the streaming multiprocessor of 4A according to one embodiment.
• 5B is a conceptual diagram of one using the PPU of 3 implemented processing system according to one embodiment.
• 5C FIG. 3 illustrates an example system in which the various architecture and / or functionality of the various previous embodiments may be implemented.
• 6 is a conceptual diagram of a by the PPU of 3 implemented graphics processing pipeline according to one embodiment.

Detailed description

In general, data is susceptible to errors caused by hardware failures (defects) such as: B. disturbances in the function of memory and / or communication channels. To detect errors in data (which may be the result of disturbed hardware or radiation interacting with the stored data), error correction code (ECC) has been introduced. When data is stored (or transferred), an ECC corresponding to the stored data is calculated; if the data is retrieved later, this calculation is performed again. If the ECC matches the results of the second calculation then the data is free from errors; if the EEC does not fit, then an error has been introduced. The ECC thus represents a "correct" form of the data. Since the EEC represents a "correct" form of the data, in some cases the EEC can also be used to correct for any errors in the data. However, the ECC itself is also susceptible to errors, particularly errors caused by disturbances in the ECC logic (circuitry), such as errors. B. Hardware faults in the encoder and / or decoder of the ECC logic. Errors in the ECC can lead to false detection of errors in the data and, worse, incorrect correction of the data, introducing further errors into the data.

The following description provides various embodiments for securing against errors in the ECC, which are particularly caused by disturbances in the ECC logic, and thus provides various fail-safe ECC logic designs. These fail-safe ECC logic designs may be used independently or in conjunction with each other and include, but are not limited to, limiting the hardware configuration of certain portions of the ECC logic (eg, the encoder and / or decoder) Computer code (algorithm) that is used by the ECC logic to modify. These fail-safe ECC logic designs ultimately protect against the above errors in the ECC by providing the ability to detect the errors and either 1) correct the ECC for use in validating the data, or 2) make the ECC uncorrectable and thus useless to identify validating the data. In addition, the fail-safe ECC logic designs can be implemented in various systems to secure the data of these systems, such as: As automotive systems and / or on artificial intelligence ("AI") based systems.

1A illustrates a flowchart of a method 100 for securing against errors in an ECC according to one embodiment. The procedure 100 can by means of ECC logic (circuit) in conjunction with a processor, such. A GPU (graphic processing unit), CPU (central processing unit) or any processor capable of protecting against errors in an ECC. In particular, the method can 100 in some optional embodiments using the parallel processing element (PPU) 300 from 3 and / or implemented in the context of any of the embodiments described below. In addition, professionals will recognize that any system that uses the procedure 100 is within the scope and spirit of embodiments of the present invention.

As in operation 110 2, a code generated for data using error correction code (ECC) logic is accessed, the code being stored in a first memory and the data stored in a second memory. Since the code is generated using the ECC logic, in the context of the present description, the code may also be referred to as an ECC generated for the data. The data may be any type of data for which validation using the code is desired, such as: For example, an instruction generated by a processor (including GPUs, CPUs, Calculation cores), an operand, an address, etc., and in this case the code can be generated to provide redundancy to the data. For example, the data may be susceptible to an error caused by a permanent failure in hardware (eg, memory, communication channel), and the code may be generated to verify that the data contains the error. Thus, the code may be generated before the data is processed by the hardware, and accordingly before the potential error is insertable into the data (eg, before the data is stored in memory and / or before the data is transmitted over the communication channel ). Furthermore, the code may be accessed with reference to the current operation when retrieved for use in validating the data from the first memory.

The operation of the ECC logic for generating the code will be described below with reference to FIG 1B described in more detail. In general, however, the ECC logic is hardware that includes an encoder that encodes the data to generate the code and a decoder that decodes the code for use in validating the data. Both the encoder and decoder are implemented in ECC logic hardware and are therefore susceptible to interference. The ECC logic can be designed as Single Error Correcting (SED), Single Error Correcting (SEC) or Single Error Correcting and Double Error Detecting (SEC-DED), and accordingly, the code generated by the ECC logic can be SED, SEC or SEC-DED ,

As mentioned above, the code is stored in the first memory and the data is stored in the second memory. In one embodiment, the first and second memories may be different physical memories. For example, in this embodiment, the first memory may be for use in storing codes generated by the ECC logic, and the second memory may be for use in storing data from which the codes are generated. In another embodiment, the first and second memories may be different portions of the same physical memory. For example, the first memory may be a first portion of the physical memory designated for use in storing codes generated by the ECC logic-generated codes, and the second memory may be a second portion of the physical memory suitable for use in storing Data from which the codes are generated is determined.

In addition, as in operation 112 shown an error in the code caused by an error in the ECC logic detected. In the context of the present description, the error in the ECC logic includes a hardware failure in the ECC logic, such as the following: For example, a single stuck-on fault in which a gate in the ECC logic is stuck at a certain value (eg, logic 0, 1, etc.). In one embodiment, the error in the code may be caused by an error in an encoder of the ECC logic that encoded the data to form the code. In another embodiment, the error in the code may be caused by an error in a decoder of the ECC logic that has decoded the code from the first memory.

Furthermore, as in Operation 114 shown determines whether the error in the code is correctable. This can be done by the decoder of the ECC logic. As in the operations 116 - 120 In response to determining that the error in the code is correctable, the error in the code is corrected to form a corrected code (Operation 116 ), the data is retrieved from the second memory (Operation 118 ) and the retrieved data is verified using the corrected code (Operation 120 ). Accordingly, the code, if corrected, can be used to verify and, if necessary, even correct the data.

As in operation 122 9, in response to determining that the error in the code is uncorrectable, the error in the code is displayed as being uncorrectable. This can prevent the erroneous code from being used for verifying and further erroneously correcting the data. For this purpose, the procedure 100 ensure the integrity of any error correction performed on the data, especially in the presence of disturbances in the ECC logic.

Additional illustrative information will now be provided on various optional architectures and features that can be used to implement the aforementioned framework to the user's liking. It is to be understood that the following information is given by way of illustration and should not be construed as limiting in any way. Each of the following features may optionally be included with or without the exclusion of other described features.

1B illustrates a block diagram of an ECC logic architecture 200 according to one embodiment. The ECC logic architecture 200 can be configured to follow the procedure 100 from 1A performs.

As shown, input data (Data In), which is n bits wide, and ECC (calculated by the encoder 210 ), which are k bits wide, in a mission memory 212 or an ECC memory 214 saved. In the present embodiment, the mission memory 212 and the ECC memory 214 different fields of the same physical memory 211 , The memory 211 has m logical locations that make up a memory array, each location comprising n + k bits of encoded data. The total capacity of the memory is m (n + k) bits. The structure of the memory array is a column decoding factor f.

The decoder 216 decodes the read out n + k bits of encoded data from the ECC memory 214 and generates a k-bit syndrome and up to three possible error indications: no error (NE), correctable error (CE) and uncorrectable error (UE). The correction logic 218 uses the k-bit syndrome to get the n-bit read data from the mission memory 212 correct if that from the decoder 216 output error indication CE is what indicates the state of correctable errors. The CE output of the decoder 216 controls the multiplex (MUX) unit 220 the unchanged data from the mission memory 212 and the corrected data from the correction logic 218 , The mux 220 and the correction logic 218 may be merged into a single entity but are shown separately to allow a more conservative posting of disturbances. Depending on the design parameter values, the ECC logic architecture 200 SED (as in parity), SEC or SEC-DED as described below.

SED (or parity): This is the case if k = 1 and the encoder 210 and the decoder 216 XOR parity trees are. In this design, the decoder signals 216 only NE and UE, and there is no correction logic 218 and mux unit 220 (separate from the in 1B shown embodiment).

SEC: For a given n, k is chosen such that 2 ^k - 1 ≥ n + k Λ 2 ^k-1 - 1 <n + k - 1. For example, if n = 32, then k = 6. (2 ⁵ - 1) <(32 + 5) Λ (2 | 6 - 1) ≥ (32 + 6). In this design of the ECC logic architecture 200 signals the decoder 216 only NE and CE. The encoder 210 and the decoder 216 are designed by special parity check equations specified by a parity check matrix. This is further described in "Error-Control Coding for Computer Systems" by TRN Rao & E. Fujiwara, Prentice Hall Series in Computer Engineering, Professor Edward J. McCluskey Series Editor, 1989, New Jersey. The ECC logic architecture 200 can optionally be configured to only detect errors; in this case, the SEC code becomes double-error-detecting (DED) code, and the decoder 216 only signals NE and UE, and as in the SED code there is no correction logic 218 and mux unit 220 ,

SEC-DED: The (n, k) SEC code selected as described above is increased to (n, k + 1) SEC-DED code. The encoder 210 and the decoder 216 have additional parity check equations for the additional check bit as described in "Error-Control Coding for Computer Systems" as mentioned above. The SECDED code can be used as a triple-error detecting TED code.

ECC protection on bus interface structures (not shown) is a special case of 1B in which the memory array and the row / column decoders are not needed. Here lies the encoder 210 at the data source level, and the decoder 216 and the correction logic 218 lie on the target of the bus interface.

1C illustrates a block diagram of the input and output of the ECC encoder 210 from 2A according to one embodiment. ECC designs are based on the theoretical structure of linear error correction codes and use EXCLUSIVE-OR (XOR) logic gate implementations. Linear code-based ECC designs have three structural components:

The encoder 210 calculates ECC, ie k check bits C [k-1: 0] from n data bits D [n-1: 0]). The calculated check bits are combined with the data bits in the ECC memory 214 or mission memory 212 saved.

1D illustrates a block diagram of the input and output of the ECC decoder 216 from 2A according to one embodiment. The decoder 216 takes the coded codeword (represented by C [k-1: 0], D [n-1: 0]) as input and determined by an intermediate k-bit output called syndrome (S [k-1: 0]), whether there is no error (NE), correctable error (CE) or uncorrectable error (UE). NE, CE, UE are mutually exclusive, with the valid results (NE, CE, UE) = (1,0,0), (0,1,0) or (0,0,1).

The correction logic 218 uses the output (S [k-1]: 0) of the decoder 216 and the CE signal to generate corrected data CD [n-1: 0] (in case of correctable errors as indicated by CE = 1), or retains the original data in the case of CE = 0.

In the ISO 26262 nomenclature, for example, the ECC logic architecture 200 in 1B considered as a safety mechanism in safety-related electronic automotive systems. In this and other embodiments, it may be used to detect and in some cases correct errors resulting from hardware failures in data. Errors in the ECC logic itself, however, can introduce errors into the ECC that should otherwise serve to protect the data. Especially permanent disturbances in the encoder 210 and / or decoder 216 can lead to data corruption without triggering an appropriate detection mechanism.

To guard against errors introduced by faults in the ECC logic itself, the ECC logic and / or code may be limited in several ways.

Embodiment 1 - SEC ECC logic restriction for encoder

For ECC logic that generates a SEC code, the ECC logic can be rendered fail-safe with respect to all single-hard-hangs interference when the ECC logic is limited so that there is no sharing of common sub-expressions in the encoder 210 for respective check bit outputs: C [0], C [1], ..., C [k-1]. Although this encoder 210 Increasing the area and power overheads, it guarantees that any single hard-hangs interference in the encoder 210 at most a single checkbit output is corrupted and any decoding of this corrupted result (ie, only a single checkbit error) will correct the same corrupted checkbit value.

Embodiment 1 - Example

For linear error detection and correction of codes including SEC codes, the check bit encoders are defined by the parity check matrix [I _kxk P _kxn ], where the identity matrix holds the check bit positions C [0] to C [k-1] in the respective k Represents lines; and the parity matrix in each row identifies the data bits that form the parity equations for the corresponding check bit. The parity check matrix shown in Table 1 below defines a (11, 4) SEC code with n = 11 data bits and k = 4 check bits. Table 1 $$\text{Parity check matrix H}=\left[\begin{array}{c}C\left[0...3\right]D\left[0...\text{10}\right]\\ 100010011101101\\ 010011001010111\\ 001011100101011\\ 000101110110101\end{array}\right]$$

1. 1. In jeder Zeile der Matrix H identifiziert das erste Bit ungleich Null an der Stelle i das Prüfbit C[i-1], und jedes nachfolgende Bit ungleich Null j1, j2, .... identifiziert jeweils Datenbits D[j1-k], D[j2-k], ....
2. 2. Die Paritätsgleichungen für jede Zeile der Matrix H werden gebildet, indem das identifizierte Prüfbit C[i-1] auf der linken Seite genommen und mit der Modulo-2 (XOR)-Summe der identifizierten Datenbits D[j1-k], D[j2-k], ... gleichgesetzt wird.

The first 4 × 4 identity sub-matrix in H corresponds to the four check bits C [0] to C [3]. The following 4 × 11 submatrix corresponds to the data inputs D [0] to D [10]. The check bit equations are canonically derived from the parity check matrix as follows:

1. 1. In each row of the matrix H, the first nonzero bit at point i identifies the check bit C [i-1], and each subsequent nonzero bit j1, j2, .... identifies data bits D [j1-k], respectively. , D [j2-k], ....
2. 2. The parity equations for each row of the matrix H are formed by taking the identified check bit C [i-1] on the left and using the modulo 2 (XOR) sum of the identified data bits D [j1-k], D [j2-k], ... is equated.

Following the above process we obtain the parity equations for the (15, 4) code shown in Table 2. Here, + denotes the modulo-2 summation. Table 2 C [0] = D [0] + D [3] + D [4] + D [5] + D [7] + D [8] + D [10] C [1] = D [0] + D [1] + D [4] + D [6] + D [8] + D [9] + D [10] C [2] = D [0] + D [1] + D [2] + D [5] + D [7] + D [9] + D [10] C [3] = D [1] + D [2] + D [3] + D [5] + D [6] + D [8] + D [10]

In the prior art, ECC logic encoders would share common sub-expressions in the parity equations. For example, D [0] + D [10] is a common sub-expression in equations for C [0], C [1], and C [2], respectively, obtained by sharing an XOR (with inputs D [0] and D [10]) gate output can be implemented with the logic structures that produce outputs C [0], C [1], and C [2].

If the interference-free data D [0 ... 10] = 11'b00000000000, then in the absence of errors, the check bits C [0 ... 3] = 4'b0000. However, with a stall 1 disturb at the output load node of the XOR gate with inputs D [0] and D [10], the check bits calculate at C [0 ... 3] = 4'b0110. When this is decoded (the decoded value would indicate single-bit error correction (CE) in the data field), the data value is incorrectly corrected because D [0 ... 10] = 11'b00000000010. Although the check bit encoder is self-checking (ie, the fault is detected by the decoder) with respect to this fault, it is not fail-safe insofar as the detected fault causes silent data corruption (SDC) because the SEC code does not contain an uncorrectable error (UE ) and may lead to violation of a security objective.

According to the above description, by limiting the ECC logic, if a single stuck-to-1 fault affects the C [0] part of the encoder logic, a data value D [0 ... 10] = 11 'results. b00000000000 in check bits at C [0 ... 3] = 4'b1000. After decoding and correction of the check bits, the read check bit and data bit values would be {C [0..3] | D [0 ... 10]} = {4'b000000 | 11'b00000000000}.

Embodiment 2 - SEC-DED ECC logic limitation for encoder

For ECC logic that generates a SEC-DED code, the ECC logic can be rendered fail-safe with respect to all single-hardship interference when the ECC logic is constrained to not share more than two common sub-expressions in the encoder 210 for respective check bit outputs: C [0], C [1], ..., C [k-1]. Although this limitation of the encoder 210 Increasing the area overheads, it guarantees that any single hard-hangs interference in the encoder 210 at most two check bit outputs are corrupted and that any decoding of this corrupted result (ie, at most two check bit errors) either corrects the same corrupted check bit value or decodes the error as uncorrectable (UE).

Embodiment 2 - Example

C[0] = D[0] + D[3] + D[4] + D[5] + D[7] + D[8] + D[10] C[1] = D[0] + D[1] + D[4] + D[6] + D[8] + D[9] + D[10] C[2] = D[0] + D[1] + D[2] + D[5] + D[7] + D[9] + D[10] C[3] = D[1] + D[2] + D[3] + D[5] + D[6] + D[8] + D[10] C[4] = D[2] + D[3] + D[4] + D[6] + D[7] + D[9] + D[10] For one (11, 4) SEC code using an additional check bit (11, 5) SEC-DED code enlarged, the parity check matrix H and corresponding check bit equations for that SEC-DED code are given in Table 3 below , Table 3 $$\text{Parity check matrix H}=\left[\begin{array}{c}C\left[0...\text{4}\right]D\left[0...\text{10}\right]\\ 1000010011101101\\ 0100011001010111\\ 0010011100101011\\ 0001001110110101\\ 0000100111011011\end{array}\right]$$

C [0] = D [0] + D [3] + D [4] + D [5] + D [7] + D [8] + D [10] C [1] = D [0] + D [1] + D [4] + D [6] + D [8] + D [9] + D [10] C [2] = D [0] + D [1] + D [2] + D [5] + D [7] + D [9] + D [10] C [3] = D [1] + D [2] + D [3] + D [5] + D [6] + D [8] + D [10] C [4] = D [2] + D [3] + D [4] + D [6] + D [7] + D [9] + D [10]

In the prior art, ECC logic encoders would share common sub-expressions in the parity equations. For example, D [0] + D [10] is a common subexpression in equations for C [0], C [1], and C [2] by sharing an XOR (with inputs D [0] and D [ 10]) gate output with the logic structures producing outputs C [0], C [1] and C [2].

If the interference-free data D [0 ... 10] = 11'b00000000000, then in the absence of interference, the check bits C [0 ... 3] = 4'b0000. However, with a single stuck-on-1 fault at the output of the XOR gate with inputs D [0] and D [10], the check bits calculate at C [0 ... 3] = 4'b11100. If this is decoded (the decoded value would indicate single-bit error correction in the data field), the data value will be incorrectly corrected since D [0 ... 10] = 11'b10000000000. However, assuming that an output load stem disturbance, as in the SEC ECC logic design described above, only damages C [1] and C [2], then the decoder signals an uncorrectable error (UE) and does not cause residual noise.

According to the above description, by limiting the ECC logic, if a single stuck-to-1 fault affects the C [0] part of the encoder logic, a data value D [0 ... 10] = 11 'results. b00000000000 in check bits to C [0 ... 4] = 5'b1000. After decoding and correction of the check bits, the read check bit and data values would be {C [0..3] | D [0 ... 10]} = {5'b000001 11'bb00000000000}. And if a single stuck-on fault affects the C [0] & C [1] part of the encoder logic, a data value D [0 ... 10] = 11'b00000000000 results in check bits of C [0 .. .3] = 5'b11000. The decoder then signals this case as a non-correctable double bit error (UE).

Embodiment 3 - Parity bit ECC logic

Parity-based encoders output SED codes and are by definition fail-safe insofar as they only generate one check bit C [0]. Any disturbance in the encoder will either damage C [0] or not. In both cases, the decoder signals an uncorrectable error or signals no error. The only downside is that it can lead to a false-positive situation and can affect the availability.

Embodiment 4 - ECC Logic Limitation for Decoder

For internal single-fixed-hang-disturbances in the decoder 216 is when guidelines like the design of the encoder 210 is followed, the syndrome logic fail-safe with respect to internal hang-glitches. In particular, the SEC decoder design is the same as in 1D with the exception that there is no decoding logic for uncorrectable errors (UE). In terms of security property of single-hard-hangs interference may be the logic of the decoder 216 So follow similar design guidelines as the logic of the encoder 210 ,

For a single bit parity decoder, the decoder is 216 a single output parity tree, and the zero error output (NE) also corresponds to the output of the parity tree.

Embodiment 5 - Modified Algorithm for ECC Logic

In the present embodiment, ECC code design techniques are described that can improve the anti-jamming property of the ECC without the need for any of the ECC logic design limitations described in the above embodiments.

To explain the code design techniques that enhance the anti-jamming performance, first let's take a look at the causes of residual noise in a regular SEC-DED design. The starting point for all ECC designs is the parity check matrix. This was demonstrated in the previous sections by constructing the encoder and decoder equations from the parity check matrix defining (11,4) and (11,5) ECC codes, respectively. 2A Figure 12 shows a construction of the parity check matrix of a standard (32.7) Hamming ECC code as described in TRN Rao & E. Fujiwara's "Error-Control Coding for Computer Systems", Prentice Hall Series in Computer Engineering, Prof. Edward J. McCluskey Series Editor, 1989, New Jersey. The 6x6 Identity Submatrix at the beginning of this Parity check matrix represents bits C [0] to C [5]. The remaining 32 column vectors of length 6 for data bits D [0] to D [31] are filled with increasing nonzero values and skipped weight 1 columns already selected for check bits in the 6x6 identity submatrix , For example, the column vector [0 0 0 0 1 1] ^T begins with the decimal value 3 for D [0] (skipping the values 1 and 2 already selected for C [5] and C [2]) and then the column vector [0 0 0 1 0 1] ^T with the decimal value 5 for D [1] (jump value 4 already selected for C [3]). This design yields a (32.6) SEC code design with check bits C [0] to C [5]. In order to obtain a SEC-DED code design, an additional check bit C [6] is added, represented by the column vector [0 0 0 0 0 1] ^T. This check bit C [6] is the overall parity of check bits C [0] to C [5] and data bits D [0] to D [31].

This parity check matrix is transformed into a systematic form, where the check bit C [6] equation is reconstructed to show only as a function of the data bit subset in D [0] to D [31]. The trick to get the last line row [6] in the parity check matrix of 2E is to perform the following bit-by-bit operation: line [6] (in 7 ) = Bit for bit XOR of lines line [0] to line [6] in 6 ,

An interesting consequence of a systematic (n, k) SEC-DED construction is that all columns in the parity check matrix are of odd weight. From the parity check matrix structure, it is also possible to predict which combination of three common XOR sub-expressions of data bits shared by multiple check bit equations. This is easily achieved by bitwise ANDing the rows according to the check bit positions. The resulting row vector with corresponding rows of data bit locations points to the common sub-expression. 2 B shows, for example, the common sub-expression for check bits 3, 4, 6 in the systematic (32.7) SEC-DED code.

By enumerating all possible sharing scenarios, we can roughly estimate that out of a total of 448 failures in the SEC-DED encoder, there are approximately 40 residual faults. This is about 8.9%. Since the SECDED decoder shares a similar design, we can expect a similar total number of residual perturbations. The local DC coverage is still greater than 91%; however, the overall diagnostic coverage of the security mechanism could fall below 90% (if we include faults in the row address decoder and the MUX units).

A major source of common sub-expression is the occurrence of odd-weighted columns greater than 3 in weight. Six out of 32 data-bit columns in the parity-check matrix of 2C have weight 5.

It is possible to construct SEC-DED parity check matrices with a systematic selection of lowest odd-weight columns. This is the basis of Hsiao's popularized code construction algorithms as described in "Error-Control Coding for Computer Systems" by TRN Rao & E. Fujiwara, Prentice Hall Series in Computer Engineering, Professor Edward J. McCluskey Series Editor, 1989 , New Jersey. The motivation for this is to minimize the number of XOR gates (and hence the number of logic levels) in the encoder and decoder circuits. It is our recent discovery that collecting least-odd-column columns also helps minimize the sharing of common sub-expressions in the encoder and decoder logic. For example, most of the (n, k) SEC DED codes can be generated by using only weight 3 columns. 2D shows such a (32,7) SECDED code.

If there are only weight 3 columns, it turns out that if there are three or more check bit or syndrome issues, there can be no sharing of any subexpression. For example, shows 2E in that only the data bit D [24] is common between the check bits C [3], C [4] and C [6], and no common XOR sub-expressions.

This leads to zero residual interference of 448 errors in the encoder. This achieves 100% local diagnostic coverage for single-squared disturbances in encoders and decoders of ECC logic designs.

1. 1. Bei gegebener Datenbreite n Bits lege Prüfbitlänge k so fest, dass: $$\left(2^{k-1}-1\right)\ge \left(n+k-1\right)\wedge \left(2|k-2-1\right)<\left(n+k-2\right).$$
   
2. 2. Erzeuge kxk Identitätsmatrix für die Prüfbits.
3. 3. Setze ungerades Gewicht w = 3, Codelänge c = n
4. 4. Iteriere getrennte Gewicht-w-Spalten bis zu min von c und $\left(\begin{array}{c}k\\ w\end{array}\right).$
   
5. 5. Wenn $\left(\begin{array}{c}k\\ w\end{array}\right)\ge c,$
   
   dann sind alle Paritätsmatrixspalten erzeugt. Gehe nach 7.
6. 6. Setze $c=c-\left(\begin{array}{l}k\\ w\end{array}\right)\text{ und }w=\mathrm{<figure-callout\; id="2"\; label="w\; +"\; filenames="DE102018123761A1\_0011.png,DE102018123761A1\_0012.png"\; state="\{\{state\}\}">w</figure-callout>}+2.$
   
   Gehe nach 4.
7. 7. Alle Paritätsprüfungsmatrixspalten erzeugt. Stopp.

Next, we show a formal method for generating a SEC-DED parity check matrix using a modified version of the Hsiao algorithm.

1. 1. For a given data width n bits set the check bit length k so that: $$\left(2^{k-1}-1\right)\ge \left(n+k-1\right)\wedge \left(2|k-2-1\right)<\left(n+k-2\right),$$
   
2. 2. Create kxk identity matrix for the check bits.
3. 3. Set odd weight w = 3, code length c = n
4. 4. Iterate separate weight w columns up to min of c and $\left(\begin{array}{c}k\\ w\end{array}\right),$
   
5. 5. If $\left(\begin{array}{c}k\\ w\end{array}\right)\ge c.$
   
   then all parity matrix columns are generated. Go to 7.
6. 6. Set $c=c-\left(\begin{array}{l}k\\ w\end{array}\right)\text{and}w=w+\mathrm{Second}$
   
   Go to 4.
7. 7. Generates all parity check matrix columns. Stop.

While some of the SEC-DED codes (such as (32,7)) may be implemented by a weight-3 parity check matrix, there will be scenarios in which odd weights greater than 3 are used. For example, for n = 256, step 1 determines k = 10. Binominal 10 choose 3 = 120 <256, so that the remaining 136 weight 5 columns are used. To mitigate this problem, one can either use the ECC logic limitations described above or increase the value of k to implement the parity check matrix with only weight 3 columns. For example, if k = 13, then it is possible to have (256,13) SEC-DED code with only weight-3 columns in the parity check matrix.

The embodiments for securing the ECC against faults described above include various fail-safe ECC logic designs that improve the overall reliability of an electronic system with ECC logic compared to conventional ECC designs. Once the ECC logic of an electronic system is made more reliable and more resistant to interference, the ECC logic can become more confident that it will perform its intended function of detecting and correcting errors in data.

Thus, fail-safe ECC logic designs can be used in memory structures, in data transfer systems, in processors, and in other systems where higher resistance to data errors is desired. Such systems include, for example, autonomous and semi-autonomous vehicles such. Automobiles, aircraft, boats, submarines, autonomous and semi-autonomous drones, security systems, robots and other electronic systems, including those exposed to external elements or extreme conditions that can cause hardware interference.

The fail-safe ECC logic designs can also be used in systems incorporating Artificial Intelligence ("AI") where greater resistance to data (bit) errors is desired. Such systems include, for example, AI-powered passenger cars, AI-operated robots in medicine, manufacturing and industry, AI-powered drones that are used in urban situations, such as mobile homes. For example, for parcel delivery, and AI-operated security systems.

For example, an automotive system for autonomous or semi-autonomous vehicles may use deep neural networks ("DNNs") for a variety of functions, including identification of lanes, objects, obstacles, pedestrians, and even occupants of the vehicle. Depending on their functions, the execution of such DNNs by a processor on the vehicle may require greater resistance to failure (including transient faults) to meet the general safety requirements of the vehicle. Because a fail-safe ECC design is more fail-safe than traditional ECC designs, replacing ECC designs with fail-safe ECC designs in the processor (s), memory structure (s), and vehicle data transfer system (s) will better protect the data used in the vehicle , In addition, the processor (s), memory structure (s) and data transmission system (s) of the vehicle may be supplemented with fail-safe ECC designs to protect data that was not previously protected by ECC to increase the resistance of such data in the vehicle. Consequently, the inclusion of fail-safe ECC designs in such vehicles will increase the overall reliability level of the data (including those applicable to their DNNs), thus, these vehicles can meet certain safety requirements, including, for example, an ASIL (Automotive Safety Integrity Level) safety standard of ISO 26262. In addition, the inclusion of fail-safe ECC designs in the other Kl and non-AI based systems mentioned above becomes the reliability also improve the data used in such systems and thus the overall resistance of such systems.

Parallel processing architecture

3 illustrates a parallel processing unit (PPU) 300 according to one embodiment. In one embodiment, the PPU 300 a multi-threaded processor implemented on one or more integrated circuits. The PPU 300 is a latency hiding architecture designed to handle many threads in parallel. A thread (ie, a thread of execution) is an instantiation of a set of commands configured to be from the PPU 300 be executed. In one embodiment, the PPU 300 a graphics processing unit (GPU) configured to implement a graphics rendering pipeline for processing three-dimensional (3D) graphics data to produce two-dimensional (2D) image data for display on a display device, such as a display device; B. to produce a liquid crystal display device (LCD device). In other embodiments, the PPU 300 be used to perform multipurpose calculations. Although illustrative of an example parallel processor is provided herein, it should be understood that this processor is provided for illustrative purposes only and any processor may be used to supplement and / or replace it.

One or more PPUs 300 can be configured to accelerate thousands of high-performance computing (HPC), data center, and machine learning applications. The PPU 300 can be configured to accelerate many systems and applications for deep learning, including autonomous vehicle platforms, deep learning, high-precision speech, image and text recognition systems, intelligent video analytics, molecular simulations, drug discovery, disease diagnosis, weather forecast, big data Analytics, astronomy, molecular dynamics simulation, financial modeling, robotics, factory automation, real-time language translation, online search optimizations and personalized user recommendations, and the like.

As in 3 shown contains the PPU 300 an input / output (I / O) unit 305, a preprocessing unit 315 , a scheduler unit 320 , a work distribution unit 325 , a hub 335 , a coupling field (Xbar, crossbar) 370 , one or more General Processing Clusters (GPCs) 350 and one or more partition units 380 , The PPU 300 can use one or more high-speed NVLink 310 Connections to a host processor or other PPUs 300 be connected. The PPU 300 can have a connection 302 be connected to a host processor or other peripherals. The PPU 300 can also be connected to a local storage, which has a number of storage devices 304 includes. In one embodiment, the local storage may include a number of DRAM (Dynamic Random Access Memory) devices. The DRAM devices may be configured as an HBM (High-Bandwidth Memory) subsystem with multiple DRAM dies stacked in each device.

The NVLink 310 connection allows systems to have one or more PPUs 300 Scale and integrate with one or more CPUs to support cache coherency between the PPUs 300 and CPUs as well as CPU mastering. Data and / or commands can be obtained from NVLink 310 over the hub 330 to / from other units of the PPU 300 be transferred, such. One or more copy engines, a video encoder, a video decoder, a power management unit, etc. (not explicitly shown). The NVLink 310 will be used in conjunction with 5B described in more detail.

The I / O unit 305 is configured to over the connection 302 Communications (ie, commands, data, etc.) are sent and received by a host processor (not shown). The I / O unit 305 can work with the host processor directly over the connection 302 or communicate via one or more intermediate devices such as a memory bridge. In one embodiment, the I / O unit 305 about the connection 302 communicate with one or more other processors, such as One or more of the PPUs 300 , In one embodiment, the I / O unit implements 305 a PCIe (Peripheral Component Interconnect Express) interface for communication over a PCIe bus, and the connection 302 is a PCIe bus. In alternative embodiments, the I / O unit 305 implement other types of known interfaces for communication with external devices.

The I / O unit 305 decodes packets over the connection 302 were received. In one embodiment, the packets represent commands that are configured to be the PPU 300 perform various operations. The I / O unit 305 transmits the decoded instructions to various other units of the PPU 300 as the commands can specify. For example, some commands may be sent to the preprocessing unit 315 be transmitted. Other commands can be sent to the hub 330 or other units of the PPU 300 be transferred, such. One or more copy engines, a video encoder, a video decoder, a power management unit, etc. (not explicitly shown). In other words, the I / O unit 305 is configured to communicate between and among the various logical units of the PPU 300 forwards.

In one embodiment, a program executed by the host processor encodes a command stream in a buffer belonging to the PPU 300 Work (workload) for processing supplies. A workload can include multiple statements as well as data to be processed by these statements. The buffer is an area in a memory on which both the host processor and the PPU 300 access (ie read / write) can. For example, the I / O unit 305 may be configured to have memory requests over the connection 302 The buffer in a system memory accesses the connection 302 connected is. In one embodiment, the host processor writes the instruction stream into the buffer and then sends a pointer to the beginning of the instruction stream to the PPU 300 , The preprocessing unit 315 receives pointers to one or more instruction streams. The preprocessing unit 315 manages one or more streams, reads commands from the streams, and forwards commands to the various units of the PPU 300 further.

The preprocessing unit 315 is with a scheduler unit 320 Coupled with the various GPCs 350 configured to handle tasks defined by the one or more streams. The scheduler unit 320 is configured to track state information about the various tasks performed by the scheduler unit 320 to get managed. The state may indicate which GPC 350 a task is assigned, whether the task is active or inactive, a priority level assigned to the task, and so on. The scheduler unit 320 manages the execution of a variety of tasks on the one or more GPCs 350 ,

The scheduler unit 320 is with a work distribution unit 325 coupled, which is configured to perform tasks on the GPCs 350 dispatches. The work distribution unit 325 can track a number of scheduled tasks by the scheduler unit 320 were received. In one embodiment, the work distribution unit manages 325 for each of the GPCs 350 a pool of pending tasks and a pool of active tasks. The pool of pending tasks may include a number of slots (e.g., 32 slots) that contain tasks performed by a particular GPC 350 to edit. The pool of active tasks may include a number of slots (eg, 4 slots) for tasks that are currently being performed by the GPCs 350 be actively worked on. If a GPC 350 When the task completes, this task is taken from the pool of active tasks for the GPC 350 and one of the other tasks from the pool of pending tasks is selected and run on the GPC 350 planned. If an active task on the GPC 350 was inactive, z. For example, while waiting for resolution of a data dependency, the active task may be from the GPC 350 while returning to the pool of pending tasks while another task is selected in the pool of pending tasks and running on the GPC 350 is scheduled.

The work distribution unit 325 communicates with one or more GPCs via the XBar 370 350 , The XBar 370 is a connection network that has many units of PPU 300 with other units of PPU 300 coupled. For example, the XBar 370 Be configured to be the work distribution unit 325 with a particular GPC 350 coupled. Although not explicitly shown, one or more other units of the PPU 300 also be connected via the hub with the XBar 370.

The tasks are handled by the scheduler unit 320 managed and distributed by the work distribution unit 325 to a GPC 350 handled. The GPC 350 is configured to process the task and generate results. The results may differ from other tasks within the GPC 350 taken over the XBar 370 to another GPC 350 forwarded or in memory 304 get saved. The results can be about the partition units 380 which provides a memory interface for reading and writing data to and from memory 304 implement in memory 304 to be written. The results can be obtained through the NVLink 310 to another PPU 304 or CPU. In one embodiment, the PPU includes 300 a number U of partition units 380 that is the number of separate and separate storage devices 304 matches that with the PPU 300 are coupled. A partition unit 380 will be in connection with 4B described in more detail.

In one embodiment, a host processor executes a driver kernel that implements an application programming interface (API) that allows one or more applications running on the host processor to perform operations on the PPU 300 to plan. In one embodiment, multiple computing applications simultaneously from the PPU 300 executed, and the PPU 300 provides isolation, quality of service (QoS), and independent address spaces for multiple computing applications. An application may generate statements (ie, API calls) that cause the driver kernel to perform one or more tasks for execution by the PPU 300 to generate. The driver kernel issues tasks to one or more streams from the PPU 300 to be edited. Each task may include one or more groups of related threads, referred to herein as a warp. In one embodiment, a warp 32 related threads that can be executed in parallel. Cooperating threads can refer to a variety of threads, including instructions for completing the task and sharing data through shared memory. Threads and cooperating threads are associated with 5A described in more detail.

4A illustrates a GPC 350 the PPU 300 from 3 according to one embodiment. As in 4A shown, each contains GPC 350 a set of hardware units to handle tasks. In one embodiment, each contains GPC 350 a pipeline manager 410 , a pre-raster operation unit (PROP) 415 , a raster engine 425 , a work distribution switch (WDX) 480 , a storage management unit (MMU) 490 and one or more data processing clusters (DPCs) 420 , Note that the GPC 350 from 4A instead of or in addition to the in 4A units shown may contain other hardware units.

In one embodiment, the operation of the GPC 350 through the pipeline manager 410 controlled. The pipeline manager 410 manages the configuration of one or more DPCs 420 for editing tasks related to the GPC 350 are assigned. In one embodiment, the pipeline manager 410 at least one of the one or more DPCs 420 configure to implement at least part of a graphics rendering pipeline. For example, a DPC 420 be configured to run a vertex shader program on the programmable streaming multiprocessor (SM) 440 performs. The pipeline manager 410 can also be configured to work from the work distribution unit 325 received packets to the corresponding logical units within the GPC 350 forwards. For example, some packages may be attached to hard-function hardware units in the PROP 415 and / or the raster engine 425 be forwarded while other packets to the DPCs 420 for processing by the primitive engine 435 or the SM 440 can be forwarded. In one embodiment, the pipeline manager 410 at least one of the one or more DPCs 420 configure to implement a model for a neural network and / or a compute pipeline.

The PROP unit 415 is configured by the raster engine 425 and the DPCs 420 Generates generated data to a raster operation (ROP) unit used in conjunction with 4B will be described in more detail. The PROP unit 415 may also be configured to perform optimizations for color mixing, organize pixel data, perform address translations, and the like.

The raster engine 425 Contains a number of fixed-function hardware units configured to perform various raster operations. In one embodiment, the raster engine includes 425 a setup engine, a Grobraster engine, a culling engine, a clipping engine, a fine grid engine, and a tile coalescing engine. The setup engine receives transformed vertices and generates plane equations associated with the geometric primitive defined by the vertices. The plane equations are passed to the Grobraster engine to generate coverage information (eg, an x, y coverage mask for a tile) for the primitive. The output of the Grobraster engine is transferred to the culling engine, where fragments associated with the primitive that do not pass a Z-test undergo culling and are transferred to a clipping engine where fragments, which are outside a viewing stub, are clipped. Those fragments that survive clipping and culling can be passed to the fine grid engine to generate attributes for the pixel fragments based on the level equations generated by the setup engine. The output of the raster engine 425 includes fragments to be processed by, for example, a fragment shader within a DPC 420 is implemented.

Everyone in the GPC 350 included DPC 420 contains an M-pipe controller (MPC) 430 , a primitive engine 435 and one or more SMs 440 , The MPC 430 controls the operation of the DPC 420 and directs those from the pipeline manager 410 received packets to the appropriate units in the DPC 420 further. For example, packets associated with a vertex may be sent to the primitive engine 435 configured to extract vertex attributes associated with the vertex from memory 304 get. In contrast, packets associated with a shader program may be sent to the SM 440 be transmitted.

The SM 440 includes a programmable streaming processor that is configured to process tasks represented by a series of threads. Every SM 440 is multi-threaded and configured to concurrently execute a variety of threads (eg, 32 threads) from a given set of threads. In one embodiment, the SM implements 440 a single-instruction, multiple data (SIMD) architecture in which each thread in a group of threads (eg, a warp) is configured to process another record based on the same instruction set. All threads in the set of threads execute the same statements. In another embodiment, the SM implements 440 a SIMT (Single-Instruction, Multiple-Thread) architecture in which each thread in a group of threads is configured to process another record based on the same set of instructions, but individual threads in the group of threads during the Execution may differ from each other. In one embodiment, a program counter, a call stack, and an execution state are maintained for each warp, allowing concurrency between warps and serial execution within warps when threads within the warp diverge. In another embodiment, a program counter, a call stack, and an execution state are maintained for each individual thread, allowing for equal concurrency between all threads, within and between warps. When the execution state is maintained for each thread, threads that execute the same instructions can be converged and executed in parallel for maximum efficiency. The SM 440 will be in connection with 5A described in more detail.

The MMU 490 provides an interface between the GPC 350 and the partition unit 380 ready. The MMU 490 can enable translation of virtual addresses into physical addresses, memory protection and arbitration of memory requests. In one embodiment, the MMU 490 One or more translation buffers (TLBs, Translation Lookaside Buffers) ready to translate virtual addresses into physical addresses in memory 304 perform.

4B illustrates a storage partition unit 380 the PPU 300 from 3 according to one embodiment. As in 4B shown contains the storage partition unit 380 a raster operation (ROP) unit 450, a level 2 cache (L2 cache) 460, and a memory interface 470 , The storage interface 470 is with the store 304 coupled. The storage interface 470 can implement 32, 64, 128, 1024-bit data buses or the like for high-speed data transmission. In one embodiment, the PPU includes 300 U memory interfaces 470 , a storage interface 470 per pair of partition units 380 where each pair is partition units 380 with an appropriate storage device 304 connected is. For example, the PPU 300 up to Y storage devices 304 be connected, such. For example, high-bandwidth or multi-rate graphics, version 5 , Dynamic random access memory or other types of persistent storage.

In one embodiment, the memory interface implements 470 an HBM2 memory interface and corresponds to Y half a U. In one embodiment, the HBM2 memory stacks reside on the same physical enclosure as the PPU 300 , resulting in significant performance and space savings over traditional GDDR5 SDRAM systems. In one embodiment, each HBM2 stack contains four memory dies and Y equals 4, the HBM2 stack having two 128-bit channels per die for a total of 8 channels and a data bus width of 1024 bits.

In one embodiment, the memory supports 304 Single Error Corrective and Double Error Detecting (SECDED) Error Correction Code (ECC) to protect data. ECC provides greater reliability for computing applications that are sensitive to data corruption. Reliability is especially important in large clustered computer environments where PPUs are used 300 process very large data sets and / or run applications for longer periods of time.

In one embodiment, the PPU implements 300 a multilevel storage hierarchy. In one embodiment, the storage partition unit supports 380 a unified memory to a single unified virtual address space for memory of the CPU and PPU 300 to provide that Sharing data between virtual storage systems. In one embodiment, the frequency of accesses to a PPU 300 tracked on memory, which resides on other processors, to ensure that memory pages in the physical memory of those PPU 300 moving more frequently to the pages. In one embodiment, the NVLink supports 310 Address translation services that make it the PPU 300 allow access directly to page tables of a CPU, and full access to CPU memory through the PPU 300 enable.

In one embodiment, copy engines transmit data between multiple PPUs 300 or between PPUs 300 and CPUs. The copy engines can create page faults for addresses that are not listed in the page tables. The storage partition unit 380 can then handle the page faults and enter the addresses in the page table, whereupon the copy engine can perform the transfer. In a conventional system, memory for multiple copy engine operations is pinned (ie, not swappable) between multiple processors, which significantly reduces available memory. With hardware page faults, addresses can be passed to the copy engines without worrying if the pages are resident, and the copy operation is transparent.

Data from the memory 304 or any other system memory may be from the storage partition unit 380 retrieved and in L2 cache 460 , which is located on-chip (on-chip) and between the various GPCs 350 is shared, saved. As shown, each storage partition unit contains 380 a part of the L2 cache 460 , the corresponding storage device 304 assigned. Subordinate caches can then be in different units within the GPCs 350 be implemented. For example, each of the SMs 440 implement a level one cache (L1 cache). The L1 cache is private memory dedicated to a particular SM 440 assigned. Data from the L2 cache 460 can be retrieved and stored in each of the L1 caches for processing in the functional units of the SMs 440 get saved. The L2 cache 460 is with the memory interface 470 and the XBar 370 coupled.

The ROP unit 450 performs graphical raster operations related to pixel color, such as: As color compression, pixel blending and the like. The ROP unit 450 also performs depth checks in conjunction with the raster engine 425 and receives a depth for a sample position associated with a pixel fragment from the raster engine culling engine 425 , The depth is tested against a corresponding depth in a depth buffer for a sample position associated with the fragment. If the fragment passes the scan position depth test, the ROP unit updates 450 the depth buffer and sends a result of the depth test to the raster engine 425 , Note that the number of partition units 380 from the number of GPCs 350 can deviate and therefore every ROP unit 450 with each of the GPCs 350 can be coupled. The ROP unit 450 keeps track of those from the various GPCs 350 received packets and determines to which GPC 350 one from the ROP unit 450 generated result by the Xbar 370 is directed. Although the ROP unit 450 in 4B within the storage partition unit 380 included is the ROP unit 450 in another embodiment, outside the storage partition unit 380 are located. For example, the ROP unit may be 450 in the GPC 350 or another unit.

5A illustrates the streaming multiprocessor 440 from 4A according to one embodiment. As in 5A shown, the SM contains 440 an instruction cache 505 , one or more scheduler units 510 , a register file 520 , one or more processing cores 550 , one or more specialized functional units (SFUs) 552 , one or more load / store units (LSUs) 554 , a connection network 580 and a shared memory / L1 cache 570.

As described above, the work distribution unit manufactures 325 Tasks to execute on the GPCs 350 the PPU 300 from. The tasks are for a particular DPC 420 within a GPC 350 and if the task is assigned to a shader program, the task can be assigned to a SM 440 be assigned to. The scheduler unit 510 receives the tasks from the work distribution unit 325 and manages the instruction scheduling for one or more thread blocks that the SM 440 assigned. The scheduler unit 510 schedules thread blocks to execute as warps from parallel threads, with each thread block assigned at least one warp. In one embodiment, each warp performs 32 Threads off. The scheduler unit 510 It may manage a plurality of different thread blocks that assign warps to the various thread blocks and then, during each clock cycle, instructions from the plurality of different cooperative groups to the various functional units (ie, cores 550 , SFUs 552 and LSUs 554 ).

Cooperative Groups is a programming model for organizing groups of communicating threads that allows developers to express the granularity with which threads communicate enables the expression of richer, more efficient parallel decompositions. Cooperative launch APIs support synchronization between thread blocks to execute parallel algorithms. Traditional programming models provide a single, simple construct to synchronize cooperating threads: a barrier across all threads in a thread block (ie, the syncthreads () function). However, programmers often want to define groups of threads with smaller granularity than thread blocks and synchronize them within the defined groups to allow for more performance, design flexibility, and software reuse in the form of shared, group-wide functional interfaces.

Cooperative Groups allows programmers to explicitly define sets of threads at the subblock (i.e., as small as a single thread) and multiblock granularities, and to perform collective operations such as subroutine operations. B. Synchronization of the threads in a cooperative group. The programming model supports clean composition across software boundaries so that libraries and utility functions can securely synchronize in their local context without having to make assumptions about convergence. Cooperative Groups Primitives enable new patterns of cooperative concurrency, including producer-consumer parallelism, opportunistic parallelism, and global synchronization across a whole network of thread blocks.

A check-in unit 515 is configured to send instructions to one or more of the functional units. In the embodiment, the scheduler unit includes 510 two dispatch units 515 which allow to send two different instructions from the same warp during each clock cycle. In alternative embodiments, each scheduler unit 510 a single check-in unit 515 or additional check-in units 515 contain.

Every SM 440 contains a register file 520 containing a set of registers for the functional units of the SM 440 provides. In one embodiment, the register file is 520 divided between each functional units, so that each functional unit a specific part of the register file 520 assigned. In another embodiment, the register file is 520 split between the different warps, that of the SM 440 be executed. The register file 520 provides temporary memory for operands associated with the data paths of the functional units.

Every SM 440 L includes processing cores 550 , In one embodiment, the SM includes 440 a large number (e.g., 128, etc.) of separate processing cores 550 , Every calculation kernel 550 may include a full pipeline, single precision, single precision, double precision, and / or mixed precision processing unit that includes a floating point arithmetic logic unit and an integer arithmetic logic unit. In one embodiment, the floating point arithmetic logic units implement the IEEE standard 754 - 2008 for floating-point arithmetic. In one embodiment, the cores contain 550 64 Einfachpräzision- ( 32 -Bit) floating point calculation cores, 64 integer calculation cores, 32 dual precision (64-bit) floating point calculation cores and 8 tensor calculation cores.

Tensor arithmetic cores are configured to perform matrix operations, and in one embodiment, one or more tensor arithmetic cores are in the cores 550 contain. In particular, the tensor calculation kernels are configured to perform deep learning matrix arithmetic such as: B. Folding operations for training and inferencing of neural networks. In one embodiment, each tensor calculator operates on a 4x4 matrix and performs a matrix multiply and accumulate operation D = AxB + C, where A, B, C, and D are 4x4 matrices.

In one embodiment, matrix multiplication inputs A and B are 16-bit floating point arrays, while accumulation arrays C and D may be 16-bit floating point or 32-bit floating point arrays. Tensor calculation kernels work on 16-bit floating-point input data with 32-bit floating-point accumulation. The 16-bit floating-point multiplication requires 64 operations and results in a high-precision product which is then accumulated using 32-bit floating-point addition with the other intermediates for 4x4x4 matrix multiplication. In practice, tensor arithmetic cores are used to perform much larger two-dimensional or higher-dimensional matrix operations composed of these smaller elements. An API, such as For example, the CUDA 9 C ++ API provides special matrix load, matrix multiplication and accumulation, and matrix memory operations to efficiently use tensor cores from a CUDA C ++ program. At the CUDA level, the warp-level interface requires matrices of size 16x16, which span all 32 threads of the warp.

Every SM 440 also contains M SFUs 552 performing special functions (eg attribute evaluation, reciprocal square root and the like). In one embodiment, the SFUs 552 a Includes a tree sweep configured to traverse a hierarchical tree data structure. In one embodiment, the SFUs 552 include a texture unit configured to perform texture map filtering operations. In one embodiment, the texture units are configured to extract texture maps (eg, a two-dimensional array of texels) from the memory 304 and sample the texture maps to produce sampled texture values for use in shader programs written by the SM 440 be executed. In one embodiment, the texture maps are stored in the shared memory / L1 cache 470. The texture units implement texture operations such as. B. Filter operations using mip maps (ie texture maps with varying degrees of detail). In one embodiment, each SM contains 340 two texture units.

Every SM 440 also includes N LSUs 554 , the load and store operations between the shared memory / L1 cache 570 and the register file 520 to implement. Every SM 440 contains a connection network 580 containing each of the functional units with the register file 520 and the LSU 554 with the register file 520 , Shared memory / L1 cache 570 combines. In one embodiment, the connection network is 580 a switch fabric that may be configured to connect any of the functional units to any of the registers in the register file 520 connects and the LSUs 554 with the register file and memory locations in the shared memory / L1 cache 570 combines.

The shared memory / L1 cache 570 is an array of on-chip memory, data storage and communication between the SM 440 and the primitive engine 435 as well as between threads in the SM 440 allows. In one embodiment, the shared memory includes / L1 cache 570 128KB storage capacity and is located in the path from the SM 440 to the partition unit 380 , With the shared memory / L1 cache 570 Read and write accesses can be cached. One or more of the shared memory / L1 cache 570 , L2 cache 460 and memory 304 are backup storage.

The combination of data cache and shared memory functionality in a single block of memory provides the best overall performance for both types of memory accesses. The capacity is usable as a cache of programs that do not use shared memory. For example, if shared storage is configured to use half the capacity, texture and load / store operations can use the remaining capacity. Integration into the shared memory / L1 cache 570 allows the shared memory / L1 cache 570 to act as a high-throughput data streaming stream while providing high-bandwidth, low-latency access to frequently reused data.

In Universal Parallel Calculation configuration, a simpler configuration can be used compared to graphics processing. In particular, the in 3 bypassed fixed-function graphics processing units, resulting in a much simpler programming model. In the Universal Parallel Calculation configuration, the work distribution unit points 325 Thread blocks directly to the DPCs 420 and distribute it on it. The threads in a block execute the same program, using a unique thread ID in the calculation to ensure that each thread produces unique results, with the SM 440 is used to execute the program and perform calculations, the shared memory / L1 cache 570 to communicate between threads and the LSU 554 to go through the shared memory / L1 cache 570 and the storage partition unit 380 to read and write to global memory. If configured for Universal Parallel Calculation, the SM 440 also write commands with which the scheduler unit 320 new work on the DPCs 420 can start.

The PPU 300 can be used in a desktop computer, a laptop computer, a tablet computer, servers, supercomputers, a smartphone (such as a wireless, portable device), a personal digital assistant (PDA), a digital camera, a vehicle, a computer Head-mounted display, a portable electronic device and the like may be included. In one embodiment, the PPU 300 formed on a single semiconductor substrate. In another embodiment, the PPU 300 together with one or more other devices, such as B. additional PPUs 300 the store 204 , a reduced instruction set computer (RISC), a memory management unit (MMU), a digital-to-analog converter (DAC), and the like in a system-on-a-chip (on-chip) system.

In one embodiment, the PPU 300 to be included on a video card containing one or more storage devices 304 contains. The graphics card may be configured to interface with a PCIe slot on a motherboard of a desktop computer. In yet another embodiment, the PPU 300 an integrated graphics processing unit (iGPU) or a parallel processor included in the chipset of the motherboard.

Example computing system

Systems with multiple GPUs and CPUs are used in multiple industries because developers are more concurrent with applications such as: B. reveal and use artificial intelligence. Powerful GPU-accelerated systems with tens of thousands of compute nodes are being used in data centers, research facilities, and supercomputers to solve more and more problems. As the number of processing devices within the high performance systems increases, the communication and data transfer mechanisms must be scaled to support the increased bandwidth.

5B is a conceptual diagram of one using the PPU 300 from 3 implemented processing system 500 according to one embodiment. The example system 565 can be configured to use the in 1A shown method 100 implemented. The processing system 500 contains a CPU 530 , a switch 510 and in each case several PPUs 300 and corresponding memory 304 , The NVLink 310 Provides high-speed communication links between each of the PPUs 300 ready. Although in 5B a certain number of connections using NVLink 310 and connection 302 can be shown, the number of connections to each PPU 300 and the CPU 530 vary. The switch 510 forms an interface between the connection 302 and the CPU 530 , The PPUs 300 , the memory 304 and the NVLinks 310 can reside on a single semiconductor platform to a parallel processing module 525 to build. In one embodiment, the switch supports 510 two or more protocols for interfacing between different different links and / or links.

In another embodiment (not shown), the NVLink provides 310 one or more high-speed communication links between each of the PPUs 300 and the CPU 530 ready, and the switch 510 forms interfaces between the connection 302 and each of the PPUs 300 , The PPUs 300 , the memory 304 and the connection 302 can reside on a single semiconductor platform to a parallel processing module 525 to build. In yet another embodiment (not shown), the compound provides 302 one or more communication links between each of the PPUs 300 and the CPU 530 ready, and the switch 510 forms interfaces between each of the PPUs 300 using the NVLink 310 to one or more high-speed communication links between the PPUs 300 provide. In yet another embodiment (not shown), the NVLink 310 provides one or more high-speed communication links between the PPUs 300 and the CPU 530 over the switch 510 ready. In yet another embodiment (not shown), the compound provides 302 one or more communication links between each of the PPUs 300 ready to go. One or more of the NVLink 310 high speed communication links may be used as a physical NVLink connection or as an on-chip or on-die connection using the same protocol as the NVLink 310 be implemented.

In the context of the present description, a single semiconductor platform may refer to a single unitary semiconductor-based integrated circuit fabricated on a die or chip. Note that the term single semiconductor platform may also refer to multichip modules with increased connectivity that simulate on-chip operation and make significant improvements over conventional bus implementation. Of course, the various circuits or devices may also be separate or arranged in various combinations of semiconductor platforms as desired by the user. Alternatively, the parallel processing module 525 may be implemented as a printed circuit board substrate and may be any of the PPUs 300 and / or memory 304 be designed as a packaged device. In one embodiment, the CPU is located 530 , the switch 510 and the parallel processing module 525 on a single semiconductor platform.

In one embodiment, the signal transmission rate is each NVLink 310 20 to 25 gigabits / second and contains every PPU 300 six NVLink 310 Interfaces (as in 5B shown are five NVLink 310 Interfaces for each PPU 300 contain). Every NVLink 310 provides a data transfer rate of 25 gigabytes / second in each direction, with six links 300 Deliver gigabytes / second. The NVLinks 310 may be used exclusively for PPU-to-PPU communication, as in 5B shown, or for any combination of PPU-to-PPU and PPU-to-CPU, if the CPU 530 also contains one or more NVLink 310 interfaces.

In one embodiment, the NVLink allows 310 direct load / memory / atomic access from the CPU 530 on the memory 304 every PPU 300 , In one embodiment, the NVLink supports 310 Coherence operations, so that from the stores 304 read data in the cache hierarchy of the CPU 530 can be stored, which is the cache access latency for the CPU 530 reduced. In one embodiment, the NVLink includes 310 Support for Address Translation Services (ATS), allowing the PPU 300 directly on page tables within the CPU 530 can access. One or more of the NVLinks 310 may also be configured for operation in a low-power mode.

5C illustrates an example system 565 in which the various architecture and / or functionality of the various previous embodiments may be implemented. The example system 565 can be configured to use the in 1A shown method 100 implemented.

As shown, is a system 565 provided, the at least one central processing unit 530 Contains that with a communication bus 575 connected is. The communication bus 575 can be implemented using any suitable protocol, e.g. PCI (Peripheral Component Interconnect), PCI Express, Accelerated Graphics Port (AGP), HyperTransport or any other bus or point-to-point communication protocol (s). The system 565 also contains a main memory 540 , Control logic (software) and data are stored in main memory 540 which may be implemented as random access memory (RAM).

The system 565 also contains input devices 560 , the parallel processing system 525 and display devices 545 that is, a conventional CRT (Cathode Ray Tube), an LCD (Liquid Crystal Display), an LED (Light Emitting Diode), a plasma display, or the like. User input can be from the input devices 560 be received, for. As a keyboard, a mouse, a touchpad, a microphone and the like. Each of the aforementioned modules and / or devices may even reside on a single semiconductor platform to the system 565 to build. Alternatively, the various modules may also be arranged separately or in various combinations of semiconductor platforms according to the wishes of the user.

Furthermore, the system can 565 for communication via a network interface 535 be coupled to a network (e.g., a telecommunications network, local area network (LAN), wireless network, wide area network (WAN) such as the Internet, peer-to-peer network, cable network, or the like).

The system 565 may also contain a secondary memory (not shown). The secondary storage 610 includes, for example, a hard disk drive and / or a removable storage drive that represents a floppy disk drive, a magnetic tape drive, a CD drive, a DVD drive, a recording device or a USB flash memory. The removable storage drive reads and / or writes in a known manner from or to a removable storage device.

Computer programs or computer control logic algorithms may reside in main memory 540 and / or the secondary storage. Such computer programs make it possible for the system 565 to perform various functions when they are executed. The memory 540 , the secondary storage and / or any other storage are possible examples of computer-readable media.

The architecture and / or functionality of the various preceding figures may be implemented in the context of a general computer system, a circuit board system, an entertainment gaming console system, an application specific system, and / or any other desired system. The system 565 For example, it may take the form of a desktop computer, a laptop computer, a tablet computer, servers, supercomputers, a smartphone (eg, a wireless, wearable device), a personal digital assistant (PDA), a digital camera, a vehicle, a head-mounted display, a portable electronic device, a mobile telephone device, a television, a workstation, a game console, an embedded system, and / or another type of logic.

Although various embodiments have been described above, it will be understood that they have been presented by way of example only, and not limitation. Therefore, the breadth and scope of a preferred embodiment should not be limited by any of the above-described embodiments, but should be defined only in accordance with the following claims and their equivalents.

Graphics processing pipeline

In one embodiment, the PPU includes 300 a graphics processing unit (GPU). The PPU 300 is configured to receive commands that specify shader programs for processing graphics data. Graphics data may be defined as a set of primitives, such as: For example, points, lines, triangles, squares, triangular stripes, and the like. Typically, a primitive contains data that is a number of Specify vertices or vertices for the primitive (eg, in a model-space coordinate system), as well as attributes associated with each vertex of the primitive. The PPU 300 may be configured to process the graphics primitive to generate a frame buffer (ie, pixel data for each pixel of the display).

An application writes model data for a scene (ie, a collection of vertices and attributes) to a memory, such as memory. For example, a system memory or memory 304 , The model data defines each of the objects that may be visible on a display. The application then makes an API call to the driver kernel requesting that the model data be rendered and displayed. The driver kernel reads the model data and writes commands to the one or more streams to perform operations to process the model data. The commands may refer to different shader programs running on the SMs 440 the PPU 300 including one or more vertex shaders, hull shaders, domain shaders, geometry shaders, and pixel shaders. For example, one or more SMs 440 be configured to execute a vertex shader program that processes a number of vertices defined by the model data. In one embodiment, the various SMs 440 be configured to run different shader programs simultaneously. For example, a first subset of SMs 440 be configured to execute a vertex shader program while a second subset of SMs 440 can be configured to run a pixel shader program. The first subset of SMs 440 processes vertex data into processed vertex data and writes the processed vertex data into L2 cache 460 and / or memory 304 , After the processed vertex data has been rasterized (ie, transformed from three-dimensional data into two-dimensional data in screen space) to generate fragment data, the second subset of SMs results 440 a pixel shader to generate processed fragment data which is then mixed with other processed fragment data and stored in the frame buffer 304 to be written. The vertex shader program and the pixel shader program may be executed concurrently, processing different data of the same scene in a pipelined manner until all model data for the scene has been rendered into the frame buffer. Subsequently, the content of the image buffer is transmitted to a display controller for display on a display device.

6 is a conceptual diagram of one of the PPU of 3 implemented graphics processing pipeline according to one embodiment. The graphics processing pipeline 600 Figure 4 is an abstract flowchart of the processing steps implemented to generate 2D computer images from 3D geometry data. As is known, pipeline architectures can more efficiently perform long latency operations by dividing the operation into a plurality of stages with the output of each stage coupled to the input of the next succeeding stage. Thus, the graphics processing pipeline receives 600 input data 601 Moving from one level to the next level of the graphics processing pipeline 600 be transferred to output data 602 to create. In one embodiment, the graphics processing pipeline 600 a defined by the OpenGL ^® API graphics processing pipeline represent. Optionally, the graphics processing pipeline 600 in the context of the functionality and architecture of the previous figures and / or any subsequent figure (s).

As in 6 shown points the graphics processing pipeline 600 a pipeline architecture that includes multiple stages. The stages include, but are not limited to, a data build stage 610 , a vertex shading level 620 , a primitive advanced level 630 , a geometry shading level 640 , a viewport scale, a cull and clip (VSCC) level 650 , a screening level 660 , a fragment shading level 670 and a raster operations level 680 , The input data 601 In one embodiment, instructions include instructions that configure the processing units to control the stages of the graphics processing pipeline 600 and implementing geometric primitives (eg, points, lines, triangles, squares, triangular stripes or fans, etc.) to be processed by the stages. The output data 602 may include pixel data (ie, color data) that is copied to a frame buffer or other type of surface data structure in a memory.

The data construction stage 610 receives the input data 601 which specify vertex data for higher-order surfaces, primitives, or the like. The data construction stage 610 collects the vertex data in a temporary memory or queue, such as By receiving a command from the host processor containing a pointer to a buffer in memory and reading the vertex data from the buffer. The vertex data is then sent to the vertex shading stage for processing 620 transfer.

The vertex shading level 620 Processes vertex data by performing a series of operations (ie, a vertex shader or a program) once for each of the vertices. Vertices can be z. B. as a 4-coordinate vector (ie, <x, y, z, w>) associated with one or more vertex attributes (eg, color, texture coordinates, surface normals, etc.). The vertex shading level 620 can single vertex attributes such. Position, color, texture coordinates, and the like. In other words, the vertex shading level performs 620 Perform operations on the vertex coordinates or other vertex attributes associated with a vertex. Such operations usually include illumination operations (ie, modifying color attributes for a vertex) and transformation operations (ie, modifying coordinate space for a vertex). For example, vertices may be specified using coordinates in an object coordinate space, which are transformed by multiplying the coordinates by a matrix that converts the coordinates from the object coordinate space to a world space or NCD space (space with normalized device coordinates ) translated. The vertex shading level 620 generates transformed vertex data that corresponds to the primitive build level 630 be transmitted.

The primitive advanced level 630 collects vertices coming from the vertex shading level 620 and groups the vertices into geometric primitives for processing by the geometry shading stage 640 , For example, the primitive build level 630 be configured to always have three consecutive vertices as a geometric primitive (ie, a triangle) for transmission to the geometry shading stage 640 grouped. In some embodiments, certain vertices may be reused for successive geometric primitives (eg, two consecutive triangles in a triangular strip may share two vertices). The primitive advanced level 630 transfers geometric primitives (ie a collection of associated vertices) to the geometry shading stage 640 ,

The geometry shading level 640 processes geometric primitives by performing a series of operations (that is, a geometry shader or a program) on the geometric primitives. Tessellation operations can generate one or more geometric primitives from each geometric primitive. In other words, the geometry shading level 640 each geometric primitive into a finer mesh of two or more geometric primitives for processing by the remainder of the graphics processing pipeline 600 divide. The geometry shading level 640 transfers geometric primitives to the Viewport SCC stage 650 ,

In one embodiment, the graphics processing pipeline 600 within a streaming multiprocessor, and the vertex shading level 620 , the primitive advanced level 630 , the geometry shading level 640 , the fragment shading level 670 and / or related hardware may sequentially perform processing operations. Once the sequential processing operations are completed, in one embodiment, the viewport may be SCC stage 650 to use the data. In one embodiment, one or more stages of the graphics processing pipeline 600 processed primitive data is written to a cache (e.g., L1 cache, a vertex cache, etc.). In this case, the Viewport SCC level 650 in one embodiment, accessing the data in the cache. In one embodiment, the viewports are SCC level 650 and the screening level 660 implemented as circuits with a fixed function.

The Viewport SCC stage 650 performs the scaling, culling and clipping of the geometric primitive. Each surface that is rendered has an abstract camera position associated with it. The camera position represents the location of a viewer looking at the scene and defines a viewing stub that encloses the objects of the scene. The viewing stub may include a viewing plane, a posterior plane, and four clipping planes. Any geometric primitive that is completely out of the view stub can be culled (ie discarded) because the geometric primitive does not contribute to the final rendered scene. Any geometrical primitive that is partly within the viewing stub and partly outside the viewing stub can be truncated (ie, transformed into a new geometric primitive that is included within the viewing stump). In addition, geometric primitives may each be scaled based on a depth of the viewing stub. All potentially visible geometric primitives are then placed in the screening stage 660 transfer.

The screening level 660 converts the geometric 3D primitives into 2D fragments (eg for display etc.). The screening level 660 can be configured to use the geometrical primitive vertices to create a set of plane equations from which various attributes can be interpolated. The screening level 660 may also compute a coverage mask for a plurality of pixels indicating whether one or more scan positions for the pixel are truncating the geometric primitive. In one embodiment, Z-testing may also be performed to determine if the geometric primitive is different from other geometric primitives already rasterized. is covered. The screening level 660 generates fragment data (ie, interpolated vertex attributes associated with a particular sample position for each covered pixel) sent to the fragment shading stage 670 be transmitted.

The fragment shading level 670 Processes fragment data by performing a series of operations (eg, a fragment shader or a program) on each of the fragments. The fragment shading level 670 can generate pixel data (ie, color values) for the fragment, e.g. By performing illumination operations or sampling texture maps using interpolated texture coordinates for the fragment. The fragment shading level 670 generates pixel data that corresponds to the raster operations level 680 be transmitted.

The raster operations level 680 can perform various operations on the pixel data, such as Alpha tests, template tests and blending the pixel data with other pixel data corresponding to other fragments associated with the pixel. When the raster operations level 680 the processing of the pixel data (ie the output data 602 ), the pixel data can be converted to a render target such as A picture buffer, a color buffer or the like.

Note that one or more additional stages in addition to or instead of one or more of the above-described stages in the graphics processing pipeline 600 can be included. Different implementations of the abstract graphics processing pipeline may implement different stages. In addition, in some embodiments, one or more of the above described stages (such as the geometry shading stage 640 ) be excluded from the graphics processing pipeline. Other types of graphics processing pipelines are contemplated as being within the scope of the present disclosure. In addition, each of the stages of the graphics processing pipeline 600 of one or more dedicated hardware units within a graphics processor, such as B. the PPU 300 be implemented. Other stages of the graphics processing pipeline 600 can be controlled by programmable hardware units such. B. the SM 440 the PPU 300 be implemented.

The graphics processing pipeline 600 can be implemented via an application that is executed by a host processor, such as B. a CPU. In one embodiment, a device driver may implement an application programming interface (API) that defines various functions that may be used by an application to generate graphical data for display. The device driver is a software program that contains a variety of instructions that govern the operation of the PPU 300 Taxes. The API provides an abstraction for a programmer that allows a programmer to use specialized graphics hardware, such as a computer programmer. B. the PPU 300 to generate the graphical data without the programmer having the specific instruction set for the PPU 300 must use. The application may include an API call to the device driver for the PPU 300 is forwarded. The device driver interprets the API call and performs various operations to respond to the API call. In some cases, the device driver may perform operations by giving instructions on the CPU 501 performs. In other cases, the device driver may at least partially perform operations by performing operations on the PPU 300 via an input / output interface between the CPU and the PPU 300 starts. In one embodiment, the device driver is configured to open the graphics processing pipeline 600 using the hardware of the PPU 300 implemented.

Within the PPU 300 Different programs can be run to the different stages of the graphics processing pipeline 600 to implement. For example, the device driver may have a kernel on the PPU 300 start at the vertex shading level 620 on a SM 440 (or multiple SMs 440 ). The device driver (or the one from the PPU 400 running initial kernel) may also have other kernels on the PPU 400 start to other stages of the graphics processing pipeline 600 execute, such. For example, the geometry shading stage 640 and the fragment shading level 670 , In addition, some of the stages of the graphics processing pipeline 600 be implemented on fixed-device hardware, such as As a rasterizer or a data assembler, in the PPU 300 is implemented. Note that results from a kernel may be processed by one or more intermediate hard-function hardware units before being taken from a subsequent kernel on an SM 440 are processed.

Machine learning

Deep neural networks (DNNs) that rely on processors such as B. the PPU 300 have been developed, have been used for various applications, from self-propelled automobiles to faster Drug development, from automatic image capture in online image databases to intelligent real-time language translation in video chat applications. Deep learning is a technique that models the neuronal learning process of the human brain, continuously learning, becoming smarter, and delivering more accurate results over time. A child is first taught by an adult to correctly identify and classify various forms in order to identify forms without tuition. Similarly, a system for deep learning or neural learning needs to be trained in object recognition and classification to make it more intelligent and efficient to identify basic objects, obscured objects, etc., and also assign context to the objects.

At the simplest level, neurons in the human brain look at various inputs that are received, each of these inputs is assigned importance levels, and outputs are routed to other neurons to respond. An artificial neuron or perceptron is the most basic model of a neural network. In one example, a perceptron may receive one or more inputs that represent various features of an object for which the perceptron is trained to recognize and classify them, and each of these features is assigned a particular weight based on the importance of that feature to the definition of the shape of an object is based.

A DNN model contains multiple layers of many connected perceptrons (eg, nodes) that can be trained with enormous amounts of input data to solve complex problems quickly and with high accuracy. In one example, a first layer of the DLL model decomposes an input image of an automobile into different parts and looks for basic patterns such as a car. Eg lines and angles. The second layer assembles the lines to look for higher-level patterns, such as, for example. As wheels, windscreens and mirrors to look for. The next layer identifies the vehicle type, and the last few layers create a label for the input image that identifies the model of a particular vehicle brand.

Once the DNN is trained, the DNN can be used and used to identify and classify objects or patterns in a process known as inference. Examples of inference (the process by which a DNN extracts useful information from a given input) include identifying handwritten numbers on checks placed in ATMs, identifying pictures of friends on photos, providing movie referrals to over fifty million users Identifying and classifying various types of automobiles, pedestrians and road hazards in driverless vehicles or translating human speech in real time.

During training, the data flows through the DNN in a forward propagation phase until a prediction indicative of a label corresponding to the input is generated. If the neural network does not correctly label the input, errors between the correct label and the predicted label are analyzed and the weights for each feature are adjusted during a backward propagation phase until the DNN correctly labels the input and other inputs in a training data set. The training of complex neural networks requires enormous amounts of parallel computing power, including floating-point multiplications and additions, by the PPU 300 get supported. Conclusion is less computationally intensive than training because it is a latency-sensitive process in which a trained neural network is applied to new inputs that previously did not exist to classify images, translate language, and generally derive new information.

Neural networks rely heavily on mathematical matrix operations, and complex multi-layered networks require massive amounts of floating point performance and bandwidth for efficiency and speed. With thousands of processing cores optimized for mathematical matrix operations and delivering tens to hundreds of TFLOPS of power, the PPU is 300 a computer platform capable of delivering the performance required for deep neural network-based artificial intelligence and machine learning applications. of the warp

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• T.R.N. Rao & E. Fujiwara, Prentice Hall Series in Computer Engineering, Professor Edward J. McCluskey Series Editor, 1989 [0050]

Claims (29)

Method, comprising: Accessing a code generated for data using error correction code (ECC) logic, wherein the code is stored in a first memory and the data is stored in a second memory; Detecting an error in the code caused by an error in the ECC logic; Determining if the error in the code is correctable; in response to determining that the error in the code is correctable: Correct the error in the code to form a corrected code, retrieve the data from the second memory, and Verifying the retrieved data using the corrected code. Method according to Claim 1 where the ECC logic includes an encoder and a decoder. Method according to Claim 2 where the error in the code is caused by an error in the encoder. Method according to Claim 2 where the error in the code is caused by an error in the decoder. A method according to any one of the preceding claims, wherein the code is generated to provide redundancy to the data. Method according to one of the preceding claims, wherein the code is one of the following: single error detection (SED), single error correcting (SEC) or single error correcting and double error detecting (SEC-DED). A method according to any one of the preceding claims, wherein the error in the ECC logic is a single stall problem. The method of any preceding claim, wherein the ECC logic is SEC and an encoder of the ECC logic is constrained to avoid any sharing of common sub-expressions for check bit outputs forming the code. Method according to Claim 8 in which, if the error is caused in the code by the encoder, the error will damage at most a single one of the check bit outputs, which is correctable by a decoder of the ECC logic. The method of any preceding claim, wherein the ECC logic is SEC-DED and an encoder of the ECC logic is constrained to avoid sharing more than two common sub-expressions for check bit outputs forming the code. Method according to Claim 10 in which, if the error is caused by the encoder in the code, the error will damage at most two of the check bit outputs which are either: correctable by a decoder of the ECC logic or decoded by the decoder of the ECC logic as being uncorrectable , The method of any preceding claim, wherein the ECC logic is SEC and a decoder of the ECC logic is constrained to avoid any sharing of common sub-expressions for bit outputs of the decoder. Method according to Claim 12 in which, if the error is caused in the code by the decoder, the error will damage at most a single one of the bit outputs which is correctable by the decoder of the ECC logic. The method of any preceding claim, wherein the ECC logic is SEC-DED and a decoder of the ECC logic is constrained to avoid sharing more than two common sub-expressions for bit outputs of the decoder. Method according to Claim 14 where, if the error is caused by the encoder in the code, the error will damage at most two of the bit outputs, either: can be corrected by the decoder of the ECC logic, or decoded by the decoder of the ECC logic as non-correctable. The method of any one of the preceding claims, wherein an algorithm used by the ECC logic is configured to select least odd-weight columns to minimize sharing of common sub-expressions in the ECC logic. The method of any preceding claim, further comprising: in response to determining that the error in the code is uncorrectable, indicating that the error in the code is uncorrectable. System comprising: an error correction code (ECC) circuit for: Accessing a code generated for data using the ECC circuit, the code being stored in a first memory and the data being stored in a second memory; Detecting an error in the code caused by an error in the ECC circuit; Determining if the error in the code is correctable; in response to determining that the error in the code is correctable: Correct the error in the code to form a corrected code Retrieve the data from the second memory, and Verifying the retrieved data using the corrected code. System after Claim 18 wherein the ECC circuit includes an encoder and a decoder. System after Claim 19 wherein the ECC circuit is SEC and the encoder of the ECC circuit is restricted to avoid any sharing of common sub-expressions for check bit outputs forming the code, or the ECC circuit is SEC-DED and the encoder the ECC circuit is limited to avoid sharing more than two common sub-expressions for check bit outputs that make up the code. System after Claim 19 wherein the ECC circuit is SEC and the decoder of the ECC circuit is restricted to avoid any sharing of common sub-expressions for bit outputs of the decoder, or the ECC circuit is SEC-DED and the decoder is the ECC circuit is limited to avoid sharing more than two common sub-expressions for bit outputs of the decoder. System according to one of Claims 18 to 21 wherein the ECC circuit further: in response to determining that the error is uncorrectable in the code, indicates that the error in the code is uncorrectable. System according to one of Claims 18 to 22 , which is further configured to perform a procedure according to one of Claims 1 to 17 can perform. Automotive system for autonomous or semi-autonomous vehicles, comprising: a memory that stores: deep neural networks for a variety of functions of the motor vehicle system, and Data used by the deep neural networks; and an error correction code (ECC) circuit for: Accessing a code generated for data using the ECC circuit, wherein the code is stored in a first part of the memory and the data is stored in a second part of the memory; Detecting an error in the code caused by an error in the ECC circuit; Determining if the error in the code is correctable; in response to determining that the error in the code is correctable: Correct the error in the code to form a corrected code, retrieve the data from the second part of the memory, and Verifying the retrieved data using the corrected code. Motor vehicle system according to Claim 24 wherein the ECC circuit includes an encoder and a decoder. Motor vehicle system according to Claim 25 wherein the ECC circuit is SEC and the encoder of the ECC circuit is restricted to avoid any sharing of common sub-expressions for check bit outputs forming the code, or the ECC circuit is SEC-DED and the encoder the ECC circuit is limited to avoid sharing more than two common sub-expressions for check bit outputs that make up the code. Motor vehicle system according to Claim 25 wherein the ECC circuit is SEC and the decoder of the ECC circuit is restricted to avoid any sharing of common sub-expressions for bit outputs of the decoder, or the ECC circuit is SEC-DED and the decoder is the ECC circuit is limited to avoid sharing more than two common sub-expressions for bit outputs of the decoder. Motor vehicle system according to one of Claims 24 to 27 where the ECC circuit serves as a safety mechanism in accordance with an ISO 26262 Automotive Safety Integrity Level (ASIL) safety metric. Motor vehicle system according to one of Claims 24 to 28 wherein the ECC circuit further: in response to determining that the error is uncorrectable in the code, indicates that the error in the code is uncorrectable.

Images