Repeated redundancy of workload

Abstract

To provide graphics processing systems and methods of processing tasks at graphics processing systems which achieve high safety goals in order to meet a safety level deemed necessary for the system.SOLUTION: In a graphics processing system, a GPU 200 has multiple processing units 204 to process a first type of respective tasks at first time and second time in order to generate respective processed outputs. A check unit 208 forms respective signatures which are characteristic of the respective processed outputs. A fault detection unit 210 compares the signatures and generates a fault signal if the signatures do not match.SELECTED DRAWING: Figure 2

Description

[Background technology]

[0001] The present disclosure relates to a graphics processing system and a method for processing tasks in a graphics processing system.

[0002] In a safety critical system, at least some of the components of the system must meet safety goals sufficient for the entire system to meet the level of safety deemed necessary for the system. For example, in most jurisdictions, seat belt retractors in vehicles must meet certain safety standards in order for vehicles equipped with such devices to pass safety tests. Similarly, tires on a vehicle must meet certain standards for a vehicle equipped with such tires to pass safety tests appropriate for a particular jurisdiction. A safety critical system is typically one whose failure would significantly increase risk to the safety of people or the environment.

[0003] Data processing devices often form an integral part of a safety-critical system, either as dedicated hardware or as a processor for running safety-critical software. For example, fly-by-wire systems for aircraft, driver assistance systems, railway signaling systems, and control systems for medical devices are all safety-critical systems that typically run on data processing devices. When a data processing device forms an integral part of a safety-critical system, the data processing device itself must meet a safety goal so that the whole system can meet an appropriate safety level. In the automotive industry, the safety level is typically the Automotive Safety Integrity Level (ASIL) as defined in the functional safety standard ISO 26262.

[0004] Also, data processing devices in safety critical systems include processors that execute software. Both hardware and software elements must meet certain safety goals. Software failures are typically systematic errors due to programming errors or poor error handling. For software, safety goals are typically achieved by rigorous development practices, code audits, and testing protocols. For hardware elements of data processing devices, such as processors, safety goals may be expressed as a set of metrics (often expressed as failures in time, or FIT), such as the maximum number of failures in a given period, and the effectiveness of mechanisms to detect single-point failures (single-point failure mechanisms, or SPFMs) and latent failures (latent failure mechanisms, or LFMs). Even if systematic errors may be completely excluded from safety critical systems, it is important that data processing hardware is designed to handle some degree of error, since random errors may be introduced into the hardware, for example, by transient events (e.g., by ionizing radiation, voltage spikes, or electromagnetic pulses). In binary systems, transient events may cause random bit flipping in memory and on the data paths of the processor.

[0005] There are various approaches to achieving safety goals in data processing hardware, for example, providing redundancy so that if one component fails, another component can perform the same task, or using check data (e.g., parity bits or error correcting codes) to allow the hardware to detect and / or correct minor data corruption. The data processor may be provided in a dual lockstep arrangement 100 as shown in FIG. 1, in which a pair of similar processing cores 101 and 102 are configured to process a stream of instructions 103 in parallel. The output of any one of the processing cores (101) may be used as the output 104 of the lockstep processor. If the outputs of the processing cores 101 and 102 do not match, a fault may occur in the safety-critical system. However, because a second processing core is required, a dual lockstep processor necessarily consumes twice the chip area and approximately twice the power compared to a conventional processor.

[0006] To improve the probability of detection of errors induced by exogenous factors such as ionizing radiation and voltage spikes, a delay 105 can be introduced at the input to one of the cores (a corresponding delay 106 is typically provided at the output of the other core). Adding additional processor cores to the lockstep processor 100 may enable it to continue to provide an error-free output, where the output of the processor is the output provided by two or more of its processing cores, and the output of a processing core that does not match the other cores is ignored. However, this further increases the area and power consumption of the processor.

[0007] Advanced driver assistance systems and autonomous vehicles may incorporate data processing systems suitable for such safety-critical applications with significant graphics and / or vector processing capabilities, but the increased area and power consumption (and therefore cost) of implementing dual lockstep processors may not be acceptable or desirable. For example, driver assistance systems often provide computer-generated graphics that show hazards, lane positions, and other information to the driver. Typically, this leads vehicle manufacturers to replace traditional instrument clusters with computer-generated instrument clusters, which also mean that displays of safety-critical information, such as speed and vehicle fault information, are computer-generated. Such processing demands may be met by graphics processing units (GPUs). However, in the automotive context, advanced driver assistance systems typically require data processing systems that meet ASIL level B of ISO 26262.

[0008] Autonomous vehicles also need to process very large amounts of data (e.g., RADAR, LIDAR, map data and vehicle information) in real time to make safety-critical decisions hundreds of times per second. Graphics processing units can also meet these processing demands, but safety-critical systems in autonomous vehicles are typically required to meet ISO 26262's most stringent ASIL level D. Summary of the Invention

[0009] This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0010] A graphics processing system is provided that includes a plurality of processing units for processing tasks, each processing unit configured to process a task independently of certain other processing units of the plurality of processing units; a check unit operable to form a signature that is characteristic of an output of the processing unit when processing the task; and a fault detection unit operable to compare the signatures formed by the check unit, wherein the graphics processing system is configured to process each task of a first type at a first and second time with the plurality of processing units to generate first and second processed outputs, respectively, the check unit is configured to form first and second signatures that are characteristic of the first and second processed outputs, respectively, and the fault detection unit is configured to compare the first and second signatures and generate a fault signal if the first and second signatures do not match.

[0011] A first processing unit of the plurality of processing units may be configured to process a task during processing at a first time, and a second processing unit of the plurality of processing units is configured to process the first task during processing at a second time.

[0012] The second processing unit may receive tasks independently of the first processing unit.

[0013] The graphics processing system may be configured such that the second processing unit is constrained to some of the multiple processing units other than the first processing unit.

[0014] The graphics processing system may be configured such that the first and second processing units are allowed to be the same processing unit.

[0015] The graphics processing system may further include a cache for holding tasks of the first type for processing on the multiple processing units, wherein the tasks of the first type are not removed from the cache when a processing unit acquires the tasks for processing at a first time.

[0016] Each task of the first type may include an identifier having at least two states: an initial state indicating that the task has not been processed at the first time, and a second state indicating that the task has been processed at the first time.

[0017] Each processing unit of the plurality of processing units may be configured to update the identifier from an initial state to a second state upon processing a task of a first type at a first time.

[0018] Each processing unit of the plurality of processing units may be configured, when accessing a cache of tasks of the first type in the graphics processing system, to obtain a task of the first type having an identifier in the second state only if the processing unit did not process that task when processed at the first time.

[0019] The graphics processing system may include an allocation unit configured to allocate tasks of a first type to the first and second processing units.

[0020] The multiple processing units may include three or more processing units.

[0021] The checking unit may be configured to store the first signature formed for the first processed output for subsequent use by the fault detection unit in comparing the first signature with the second signature.

[0022] Each task of the first type may be a safety task that is treated according to a predefined safety level.

[0023] Each task of the second type may be processed only at a first time on multiple processing units to generate a respective single processed output.

[0024] Each task of the second type may be a non-safety task that is not processed according to a predefined safety level.

[0025] The checking unit may be arranged not to form a signature that is characteristic of a single processed output.

[0026] The graphics processing system may further include one or more other processing units configured to process tasks of a second type, the one or more other processing units configured to process each task of the second type only at the first time.

[0027] The graphics processing system may further include a data store to which the graphics processing system is configured to write one or more processed outputs for each task of the first type.

[0028] The graphics processing system may be configured to write only one of the first and second processed outputs to a data store.

[0029] The check unit may be configured to read back the processed data written to the data store for the first type of task to generate a further signature that is characteristic of the processed data held in the data store, and the fault detection unit is configured to compare the further signature with one or both of the first and second signatures generated by the check unit for the same task of the first type, and the fault detection unit is configured to generate a fault signal if the further signature does not match one or both of the first and second signatures.

[0030] The plurality of processing units, the checking unit and the fault detection unit may be provided in a graphics processing unit of a graphics processing system; The checking unit may be configured to make the first and / or second signatures available to a second checking unit external to the graphics processing unit, the second checking unit being configured to read back processed data written to the data store by the graphics processing unit for the first type of task in order to generate a further signature characteristic of that processed data held in the data store; A second fault detection unit provided in the second check unit may be configured to compare the further signature with one or both of the first and / or second signatures made available by the check unit for the same task of the first type, the second fault detection unit being configured to generate a fault signal if the further signature does not match one or both of the first and second signatures.

[0031] The data store may include one or more memories located external to the graphics processing unit of the graphics processing system, and / or one or more caches located on or external to the graphics processing unit of the graphics processing system.

[0032] The checking unit may be configured to form a signature characteristic of each of the processed outputs from one of the multiple processing units by performing one or more of a checksum, a CRC, a hash, and a fingerprint on the processed data.

[0033] The processed data may include one or more memory addresses associated with each processed task.

[0034] Each task of the first type may be associated with a tile, and the graphics processing system is configured to perform tile-based graphics rendering.

[0035] The fault signal may include one or more of a control message, a flag, an interrupt, a signal for setting one or more register bits, a data packet, and a signal for writing data to a data store.

[0036] A method of processing tasks in a graphics processing system having a plurality of processing units, each configured to process tasks independently of several other processing units, is provided, the method including, upon receiving a first type of task for processing, processing the task at a first time with a first processing unit and forming a first signature characteristic of an output of the first processing unit, processing the task at a second time with a second processing unit and forming a second signature characteristic of an output of the second processing unit, comparing the first and second signatures, and generating a fault signal if the first and second signatures do not match.

[0037] The graphics processing system may be embodied in hardware on an integrated circuit. A method of manufacturing a graphics processing system on an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided that, when processed on the integrated circuit manufacturing system, configures a system for manufacturing the graphics processing system. A non-transitory computer readable storage medium may be provided having a computer readable description of the integrated circuit stored thereon, external to the integrated circuit, for causing the integrated circuit manufacturing system to manufacture the graphics processing system.

[0038] An integrated circuit manufacturing system may be provided, comprising a non-transitory computer readable storage medium having stored thereon a computer readable integrated circuit description that describes a graphics processing system, a layout processing system configured to process the integrated circuit description to generate a circuit layout description of an integrated circuit embodying the graphics processing system, and an integrated circuit generation system configured to manufacture the graphics processing system in accordance with the circuit layout description.

[0039] Computer program code may be provided for performing the methods described herein. A non-transitory computer readable storage medium may be provided having computer readable instructions stored thereon that, when executed on a computer system, cause the computer system to perform the methods described herein. [Brief description of the drawings]

[0040] The invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 shows a conventional dual lockstep processor. [Diagram 2] 1 illustrates a graphics processing system configured in accordance with the principles described herein. [Diagram 3] 1 illustrates a data processing system including a graphics processing system configured in accordance with the principles described herein. [Figure 4] FIG. 2 is a schematic diagram illustrating the operation of the graphics processing system according to the first embodiment. [Diagram 5] FIG. 11 is a schematic diagram illustrating the operation of a graphics processing system according to a second embodiment. [Figure 6] FIG. 11 is a schematic diagram illustrating the operation of a graphics processing system according to a third embodiment. [Figure 7] FIG. 11 is a schematic diagram showing the operation of a graphics processing system according to a fourth embodiment. [Figure 8] 1 is a flow chart illustrating the operation of a graphics processing system configured in accordance with the principles described herein. [Figure 9] FIG. 13 is a schematic diagram showing the operation of a graphics processing system according to a fifth embodiment. [Figure 10] 1 is a schematic diagram of an integrated circuit manufacturing system. [Figure 11] 1 is a flow chart illustrating the operation of a graphics processing system configured in accordance with the principles described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0041] The following description is presented by way of example to enable those skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described by way of example only.

[0042] The present disclosure relates to a graphics processing system including multiple processing units operable to process multiple tasks in parallel. A graphics processing system configured according to the principles herein may have any suitable architecture, for example, the system may be operable to perform immediate mode rendering or tile-based rendering (including tile-based deferred rendering), and / or any type of graphics, image or video processing, and / or general processing. In an embodiment, the processing units of a graphics processing system may be configurable such that different processing units can perform different sets of actions at a given point in time and / or such that a given processing unit can perform different sets of actions at different times. Each processing unit may be capable of processing a task independently of any other processing unit. Thus, a task processed by one processing unit may not cooperate with another processing unit to process the task (e.g., an individual task is not processed in parallel by multiple processing units, but an individual task may be processed in parallel by a single processing unit).

[0043] The processing units may be, for example, any kind of graphical and / or vector and / or stream processing units. The processing units may include a rendering pipeline. Each processing unit may be a different physical core of a GPU. Graphics processing systems may be applied to general computational tasks, especially those that can be easily parallelized. Examples of general computational applications include signal processing, audio processing, computer vision, physical simulation, statistical computing, neural networks, and cryptography.

[0044] A task may be any piece of work to process with a graphics processing unit, including all or part of a scene for rendering to memory or a display screen, all or part of an image or video frame, or any other data. Tasks for graphical processing applications may relate to any aspect of graphics processing, including tiling, geometry calculations, texture mapping, shading, anti-aliasing, ray tracing, pixelation, and tessellation. In a tiled renderer, each task may relate to a tile. More generally, a task need not relate to processing of graphical data. For example, a task may be any kind of data that a processing unit of a graphics processing system may be configured to process, such as vector data. A graphics processing system may be configured to operate on multiple different types of tasks. In some architectures, different processing units or groups of processing units may be assigned to process different types of tasks.

[0045] FIG. 2 illustrates a graphics processing system configured according to the principles described herein as illustrated in FIG. A graphics processing unit (GPU) 200 is part of the graphics processing system. The GPU 200 includes a number of processing units 204, labeled in the diagram as PU0 through PU(n). The GPU 200 may include one or more caches and / or buffers 206 configured to receive data 202 from a memory 201 and provide processed data 203 to the memory 201. The memory 201 may include one or more data storage units arranged in any suitable manner. Typically, the memory 201 will include one or more of memory dedicated to the GPU, a frame buffer, and system memory of a computer system in which the GPU is supported. In some implementations, at least a portion of the memory 201 may be considered to form part of the graphics processing system.

[0046] The various units of the GPU 200 may communicate through one or more data buses and / or interconnects 205. The GPU may include firmware 207, for example, providing low-level control of the units of the GPU.

[0047] Each of the GPU's processing units 204 is operable to process a task, with the processing units being arranged such that each of the multiple processing units can execute a respective task simultaneously. In this manner, the GPU can process multiple tasks simultaneously. Each task is arranged to process a portion of data received by the GPU, for example from memory 201. Each processing unit may include multiple configurable functional elements (e.g., shaders, geometry processors, vector processors, rasterizers, texture units, etc.) to allow a given processing unit to be configured to perform a range of different processing actions. A processing unit may process a task by performing a set of actions on the data portion for the task. A set of actions may be defined as appropriate for a given task, for example, in a system where a task relates to each tile of a frame and each tile includes multiple primitives, the set of processing actions may include geometry processing, shading, texturing, etc. The processing units may be configured, for example, by a software driver for the GPU, to pass appropriate instructions to firmware 207 to enable / disable functional elements of the processing units so that the processing units can perform different sets of processing actions. In this manner, a first set of processing units may be configured, for example, to perform shader processing on graphical tasks that represent portions of a computer-generated image of a scene (e.g., a tile), while another set of processing units may be configured, for example, to perform vector processing of sensor data received from vehicle sensors.

[0048] In processing a task, the processing unit 204 generates output data for that task. The GPU 200 includes a check unit 208 operable to receive output data from the processing unit and form a signature that is characteristic of the output data. The check unit may, for example, perform a checksum, hash, CRC, or fingerprint calculation on the output data. The check unit operates on at least the data generated on the processing unit processing the task. The check unit preferably further operates on memory addresses and / or control data associated with the generated data, whereby the verification operations described herein may help identify a wider range of faults. The signature provides a representation of the processing performed on the task by the processing unit in a more compact form than the output data itself, so as to facilitate comparison of output data provided by different processing units. The check unit preferably forms the signature over all of the output data (not including the control data) received from the processing unit for the task, although the signature may be formed over a portion (e.g., none) of the output data received from the processing unit for the task. The check unit 208 may receive output data from the processing unit on the data bus / interconnect 205 .

[0049] The check unit 208 may include a data store 209 for storing one or more signatures formed by the check unit. Alternatively or additionally, the check unit may use a data store external to the check unit (e.g., memory of the GPU 200) to store one or more signatures formed by the check unit. The check unit may receive output data from all or a subset of the processing units of the GPU. The check unit may include multiple check unit instances, e.g., each check unit instance may be configured to receive output data from a different subset of the processing units of the GPU.

[0050] The GPU 200 further includes a fault detection unit 210 configured to compare the two or more signatures formed by the check unit 208. The fault detection unit 210 is configured to generate a fault signal 211 based on a determination that the signatures do not match. The fault may lead to a safety violation in the GPU. The fault signal may be provided in any suitable manner as an output of the GPU 200. For example, the fault signal may be one or more of control data, an interrupt, data written to the memory 201, and data written to a register or memory of the GPU 200 to which the GPU is connected.

[0051] The fault detection unit 210 is for comparing signatures of output data from different processing units 204 arranged to process the same task. Two or more processing units may be arranged to process the same task, and the processing performed by the processing units may or may not be performed simultaneously. If only two processing units are arranged to process the same task, comparing the signature characteristics of the output data from the processing units indicates whether the processing performed by the pair of processing units is consistent. If the signatures of a pair of processing units for a given task do not match, a fault signal 211 indicates that a fault has occurred in one of the processing units of the pair, but the fault signal does not indicate which unit experienced the fault.

[0052] When a group of three or more processing units are arranged to process the same task, comparing the signature characteristics of the output data from those processing units indicates whether the processing performed by the processing units is consistent. If the signatures of each of the group of processing units for a given task do not match, the fault signal 211 indicates that a fault has occurred in one of the processing units of the group, and may further indicate that a fault has occurred in either one of the processing units of the group. This is because a fault can be assumed to have occurred in the processing unit whose signature does not match the signatures of the output from two or more other processing units.

[0053] Typically, the GPU 200 would be incorporated into a data processing system, such as the data processing system 300 of FIG. 3. Such a data processing system may include other processors, such as a central processing unit (CPU) 304 and memory 201. The hardware 302 may include one or more data buses and / or interconnects 308, over which the processors 200, 304 and memory 201 may communicate. In general, a software environment 301 is provided for the data processing system on which a number of processes 307 may be implemented. An operating system 306 may provide an abstraction of the available hardware 302 to the processes 307. The operating system may include a driver 309 for the GPU to expose the functionality of the GPU to the processes. All or part of the software environment 301 may be provided as firmware. In one embodiment, the data processing system 300 forms part of a vehicle control system, with the processes each performing one or more control functions of the vehicle, such as, for example, an instrument cluster display, an entertainment system, engine management, climate control, lane control, steering compensation, an automatic braking system, etc. One or more of the processes 307 may be safety critical processes. The processes may be a mix of safety critical processes that must be performed in accordance with a predefined safety level and non-safety critical processes that do not need to be performed in accordance with a predefined safety level.

[0054] The fault signal may be used in any manner by the data processing system 300 in which the GPU is incorporated. For example, upon a fault signal generated by a fault detection unit, the system in which the GPU is incorporated may discard output data formed in association with the target task and / or resubmit the task to the GPU for reprocessing. A graphics processing system configured according to the principles described herein may include other elements in addition to the GPU, such as a software driver 309 for the GPU. The graphics processing system itself may use the fault signal 211. For example, the graphics processing system may log fault signals and the processing units with which those faults are associated, and if one or more processing units exceed a predefined number of faults (perhaps within a defined period of time), those one or more processing units may be disabled or otherwise prevented from processing tasks received by the GPU.

[0055] A graphics processing system such as that shown in FIG. 2 is operable to process tasks to meet a predefined safety level. For example, the graphics processing system may be certified to meet ASIL B or ASIL D standards of ISO 26262. The tasks requiring processing to a predefined safety level may be tasks related to safety-critical functions of the data processing system 300 in which the graphics processing system may be embedded. For example, in an automotive application, the safety-critical tasks may be tasks related to rendering of an instrument cluster and / or image processing of data captured by one or more vehicle cameras for use in a lane assistance system.

[0056] In some embodiments, the GPU performs tiled rendering, where each task that its processing units perform is associated with a tile.

[0057] Repetitive Workload The operation of the graphic processing system of FIG. 2 will now be described with respect to a first example shown in FIG. 4 and a flow chart shown in FIG. 8. FIG. 4 includes two schematic diagrams (a) and (b), which show the operation of the GPU 200 on processing tasks related to safety-critical functions. In FIG. 4(a), a pair of processing units 405 and 406 of the plurality of processing units 204 is arranged to receive tasks for processing from a workload of tasks 407. Typically, a GPU has three or more processing units. The workload 407 may be, for example, a buffer of tasks 410 in the cache 206. For clarity, in the figure, the workload 407 is shown schematically separate from the cache, but may be supported in the cache and / or other data stores of the GPU (including the processing units themselves) and / or outside the GPU (for example, in the external memory 201). Each task received for processing 701 may be a safety task that is processed according to a predefined safety level.

[0058] Each task 410 is received at a processing unit for processing. This may be accomplished in any suitable manner, and in general, a GPU may have any type of architecture and may utilize several schemes for allocating tasks to processing units. In the example shown in FIG. 4, a demultiplexer 402 is shown generally allocating tasks to processing units 405 and 406. The demultiplexer 402 generally represents the distribution of tasks among the processing units and does not imply the presence of a unit for explicitly allocating tasks to the processing units. For example, each processing unit 204 may be configured to request or otherwise receive a task from a workload 407. A processing unit may be configured to obtain one or more tasks from the workload 407 as and when the processing unit is able to begin processing that task. The demultiplexer 402 may be any type of allocation unit for allocating tasks to the processing units. The demultiplexer can assign tasks to processing units by marking or otherwise identifying tasks of a workload as being processed by a particular processing unit; for example, the demultiplexer can assign a task to a processing unit by assigning the task to an input buffer of the processing unit from which the processing unit obtains the task.

[0059] Each task may be processed by any of a number of processing units. Although only two processing units 405 and 406 are shown in FIG. 4, there will typically be many more. The number of processing units available to process tasks in the techniques described herein may be a subset of the total number of processing units in the graphics processing system.

[0060] An arbitration unit 401 may be provided to arbitrate communication of data around the GPU (e.g., data bus and / or interconnect 205). The arbitration unit may be configured to direct tasks received from external memory 201 (optionally via cache 206) to a workload 407 for processing by the processing unit. The arbitration unit may be configured to direct data processed by the processing unit to external memory 206 (optionally via cache 206) and to check unit 208.

[0061] The check unit 208 is configured to receive the output data by each processing unit 204 and form a signature that is characteristic of the output data. For a task processed by a processing unit, the signature of the output of each of the processing units may be stored by the check unit in the data store 209. For example, referring to FIG. 4(a), for a task T0 processed by processing unit 405, the signature 403 of the output of processing unit 405 may be stored in the data store 209.

[0062] To meet the required safety level, the GPU is configured to process all of the safety tasks of the workload 407 at least twice: a first time 702 on a first processing unit and a second time 704 on a second processing unit. As described, the first and second processing units may or may not be the same processing units, depending on the particular implementation. Each processing instance of a task is called a pass. Each pass of a given task may or may not be processed simultaneously with one or more other passes. An iteration of task processing is illustrated in FIG. 4(b), where tasks of the repeated workload 408 are processed on processing units 405 and 406. In general, a task may be processed a first time on any of the processing units of the multiple units, and a second (or further) time on any of the processing units of the multiple units. This has the advantage that tasks (whether for the first pass or a further pass) can be dynamically assigned to processing units in a manner that efficiently spreads the processing load and avoids idle processing units. The repeated workload is generalized and represents a set of tasks whose processing is repeated on the GPU.

[0063] In some embodiments, at least some of the tasks of the repeating workload 408 are not read for a second time from external memory, and the tasks of the workload 407 are reused by having the processing unit process the tasks for a second time. This avoids unnecessary reads from external memory that consume bandwidth and waste power. However, this may be a drain on isolation between processing paths. In some embodiments, the tasks may be read independently from memory for each process path of the tasks. This may help protect against data corruption of data cached in the GPU.

[0064] In the example shown in FIG. 4, processing units 405 and 406 can receive any task from workload 407 or 408. More generally, any of the multiple processing units may be able to receive any task of the workload. In FIG. 4(a), it can be seen that when processing the tasks of the workload at a first time, processing unit 405 receives tasks T0 and T1, and processing unit 406 receives tasks T2 and T3. Since tasks may be received at either processing unit, when the workload is repeated, as shown in FIG. 4(b), processing unit 405 happens to receive tasks T1 and T2, and processing unit 406 receives tasks T0 and T3. Thus, tasks T0 and T2 are processed once at each processing unit, but tasks T1 and T3 are processed twice at the same processing unit.

[0065] For each task processed in the first pass shown in Fig. 4(a), a signature 403 is formed 703 in the check unit 208. The signature 403 may be stored in the data store 209. For tasks processed in the second pass shown in Fig. 4(b), a signature 404 is formed 705 in the check unit 208 for each task processed in the second pass. The signature 404 may be stored in the data store 209. The fault detection unit 210 is configured to compare 706 the signatures 403 and 404 formed in relation to the first and second processing passes of the task. If the signatures do not match 708, then a fault signal 211 is generated. If the signatures match 709, then the processed task data generated by the graphics processing system for the task is considered valid and may be used in a manner appropriate to the application (e.g., in an automotive context, the processed task data may represent graphical data for output to an instrument console). If the signatures match, then no fault signal may be generated, or in some embodiments, a signal may be generated indicating that the signatures match. Non-matching signatures indicate that the processed output from the two paths is not the same, and thus the processed output from one or both of the processing unit(s) is invalid. The output of processing unit(s) configured to process the same task may differ due to transient events such as ionizing radiation or voltage spikes, or permanent errors due to bugs in some combination of hardware, software, and firmware.

[0066] The fault signal may be any type of indication that a fault has occurred including, for example, a control message, an interrupt, one or more of a flag in the control data, one or more bits set in a register, and a data packet.

[0067] 4, the workloads are shown to be processed sequentially in time (i.e., tasks in workload 407 are processed followed by tasks in workload 408). In general, the processing of tasks may be repeated in one or more different ways, including by processing the same task simultaneously on different processing units, by including multiple copies of the same task in the workload so that the task is processed multiple times, by having the workload hold tasks assigned to a processing unit so that they remain available for further processing on the same / another processing unit.

[0068] Each task in the workload may be processed three or more times with the signature formed by the checking unit 208 for each pass of the task through the processing units. This may allow the GPU to continue to provide valid output even if one of the processing passes is corrupted. The output of the processor may be provided by most of the processing cores that process a particular task, and the output of the processing cores that do not match the other cores are ignored. However, this may increase the area, power consumption and latency of the processor.

[0069] The graphics processing system may be configured to write one or more of the processed outputs generated in the processing unit(s) for each task to the external memory 201. To minimize consumed memory bandwidth, it may be advantageous to provide only one of the processed outputs to the external memory. The output of the first processing unit for processing a task may be written 710 to the external memory once the respective signature is formed in the check unit, and the outputs of the further processing units may be discarded. This may have the advantage of making the processed tasks available earlier for the data processing system in which the GPU is placed. If the fault detection unit determines that the processed tasks written to the external memory (or in a cache for writing to the external memory) are invalid, the graphics processing system may be configured to discard and / or mark the processed tasks as invalid. The output of the last processing unit for processing a task may be written to the external memory, and the outputs of the previous processing units may be discarded. This may have the advantage that, once the output of the last processing unit is known, all signatures are available for comparison in the fault detection unit. This avoids memory bandwidth being unnecessarily consumed by writing out invalid data. In general, all or one or more of the outputs from a processing unit arranged to process a given task may be written out to memory 201.

[0070] A graphics processing system configured according to the principles described herein may be operable to process both (a) safety tasks, which are tasks related to safety-critical functions, and (b) normal tasks, which are not related to safety-critical functions and therefore do not require repetitive processing. This arrangement is feasible in the graphics processing systems described herein because each processing unit of the system may be assigned to process any given task independently of any other processing unit, allowing different processing units to process different tasks. Furthermore, each instance of a particular task may be independently assigned to a processing unit of the system. Both safety tasks and normal tasks may be processed simultaneously on different processing units of the system. A normal task 715 received for processing at the graphics processing system may be processed 716 by a processing unit in a conventional manner and written 717 to memory without checking the processed output from the processing unit assigned the normal task.

[0071] The graphics processing system described herein provides a significant advantage over conventional lockstep processors, where both of the processing cores of a lockstep processor must both process the same task even if that task is not related to a safety-critical function. Lockstep processors suffer from the problem that their two (or more) cores are locked together and cannot be utilized individually, resulting in an inflexible 100% chip area cost for all tasks processed.

[0072] Depending on the architecture of the graphics processing system, flags can be used to identify the safety tasks. For example, tasks submitted to the graphics processing system by a data processing system provided with a GPU can be marked with a flag so that the graphics processing system repeats the processing of those tasks according to the principles described herein. Of course, safety tasks can be identified in many different ways, for example by a register, list, or other data set that identifies which tasks are safety tasks. Tasks can be assigned specific identifiers to allow them to be unambiguously identified.

[0073] In some embodiments, based on receiving a task identified as a safety task, the demultiplexer 402 may responsively assign the task to a plurality of processing units for processing at those units. Upon identifying the processed data associated with the safety task, the arbitration unit 401 may be configured to send the processed data to a check unit to responsively generate a signature for the processed data. The arbitration unit may be configured to cause one or more of the outputs from the process units for the safety task to be written to the memory 201 (e.g., by writing the / their outputs to the cache 206). A flag identifying the safety task may be passed to the data output processed by the processing units for that task (or a separate flag may be provided for such processed data).

[0074] Regular tasks do not require repeated processing because the GPU does not need to meet a predefined safety level when processing these tasks. Such regular tasks may be assigned to a single processing unit for processing, and the processed data output from that processing unit is written to memory. It is advantageous if a signature is not formed for the processed regular tasks. This can avoid unnecessary power consumption in the GPU. In some embodiments, a different subset of one or more processing units may be assigned to process regular tasks, and a subset of the processing units may be used exclusively to process regular tasks, and other processing units of the multiple processing units may be used exclusively to process safety tasks. This can help isolate safety tasks from errors, data corruption, and security issues caused by regular tasks running on the same processing unit.

[0075] Allowing repeated processing of a task to be executed on any processing unit of a graphics processing system provides protection against transient events. However, a processing unit may cause a permanent fault that may cause the processing unit to provide invalid output each time it processes a given task. In the approach illustrated in FIG. 4, the processing of a task may be repeated on the same processing unit, and thus this approach may not detect a permanent fault.

[0076] Repeating the workload on different processing units To improve the safety characteristics of the GPU, it may be advantageous to ensure that each safety task is processed by two or more different processing units. This approach is illustrated in the example shown in FIG. 5 with an exemplary flow chart for the approach shown again in FIG. 8. The system shown in FIG. 5 operates similarly to the system shown in FIG. 4 described above, but the system shown in FIG. 5 ensures that a safety task assigned to processing unit 405 in a first pass shown in FIG. 5(a) is assigned to processing unit 406 in a second pass shown in FIG. 5(b), and vice versa. For example, tasks T0 and T2 are processed by processing unit 405 in a first pass but processing unit 406 in a second pass, and tasks T1 and T3 are processed by processing unit 406 in a first pass but processing unit 405 in a second pass.

[0077] The checking unit 208 is configured as described above to form a signature characteristic of the output from each processing unit for each safety task. The fault detection unit 210 is configured as described above to compare two or more signatures (depending on the number of times the processing of a task is repeated) characteristic of the output from different processing units arranged to process the same task and to generate a fault detection signal 211 if their signatures do not match.

[0078] In some embodiments, the graphics processing system will include a plurality of three or more processing units. In general, a given safety task may be processed on any two or more different processing units of the plurality of processing units. This may be accomplished in any suitable manner. For example, a first instance of the task may be assigned to any of the processing units, and a second instance of the task may be assigned to any processing unit other than the processing unit to which the first instance of the task was assigned. Further instances of the task (e.g., in a system configured to process three or more safety tasks) may be handled in the same manner, e.g., with the further instances of the task being assigned to some processing units where the task is not already being processed. Such an assignment may be performed, for example, by the demultiplexer 402 in FIG. 5. By allowing a task to be dynamically assigned to any available processing unit that has not previously been processed, the processing units of the graphics processing system may be efficiently utilized.

[0079] To know which processing units have been previously assigned, a log (e.g., a lookup table) may be maintained in the graphics processing system (e.g., in a data store accessible to the demultiplexer 402) to identify which processing units each task has been assigned to. Each task may include an identifier so that each task may be uniquely referenced in the log. Each task may include an identifier (e.g., a flag) indicating whether the task has been previously assigned to a processing unit and / or the number of times the task has been previously assigned to a processing unit. For example, each task may initially have a flag set (e.g., a state bit in the control stream) indicating that the task is not assigned to a processing unit and is subject to first pass processing. Upon assignment to a processing unit for the first pass, the flag may be cleared for the task held in the workload (e.g., in a cache) to indicate that the task is available for processing in its second pass.

[0080] When assigning a task to a processing unit in a second or subsequent pass, the log may be referenced to identify the processing unit(s) to which the task was assigned. In response, the task may be assigned to any other processing unit. The lookup of the task in the log may or may not be responsive to a flag indicating that the task has been previously assigned. In some implementations, an identifier of the processing unit(s) to which the task was previously assigned may be written to or otherwise associated with the task in a data store that holds the workload (e.g., cache 206). This may avoid the need to separately look up the log to identify that a processing unit(s) has been previously assigned to the task.

[0081] In some embodiments, the assignment of tasks to processing units is performed by the processing units themselves. For example, each processing unit may request or otherwise obtain work from the workload (e.g., in cache 206) as and when processing capacity becomes available at the processing unit (e.g., when the processing unit can accept tasks into its pipeline). Each processing unit may perform any of the approaches described herein to determine whether a task has been previously processed at the processing unit. For example, the processing unit may read a flag at the next available task in the workload to determine whether the task has been previously processed. If the flag indicates that the task has been previously processed, the processing unit determines whether it has processed the task (e.g., by a lookup in a log) and, if it has, skips the task and does not process it; if it has not, the processing unit proceeds to process the task.

[0082] In some embodiments, the tasks of the workload may be at least logically disposed in the input buffer of each processing unit. When assigned to a first processing unit, the graphics processing system (e.g., demultiplexer 402) may be configured to add the tasks to the input buffer for the different processing unit. This approach allows each processing unit to process the tasks in its respective input buffer without using the graphics processing system, at which point it needs to check whether the processing unit has previously processed that task.

[0083] In some embodiments, the processing units may be logically arranged in groups of two or more processing units, with a given task of the workload being assigned to a processing unit of that group. Different tasks may be assigned to different groups of processing units for initial stage and iterative processing. For example, a group may include a pair of processing units, and the graphics processing system may be configured to process a safety task twice, and a given task may be assigned to the pair of processing units for initial stage and iterative processing. In the embodiment shown in FIG. 5, for example, the demultiplexer 402 may be configured to assign each task of the workload to the pair of processing units 405 and 406. Each processing unit may then process its task in order (e.g., upon completing processing of its current task). In some embodiments, the tasks of the workload may be numbered, and the tasks are assigned to the processing units based on their numbers. 5, in a first pass, even numbered tasks may be assigned to processing unit 405 and odd numbered tasks may be assigned to processing unit 406, and when repeating the processing of tasks in a second pass, the assignments may be reversed, with even numbered tasks assigned to processing unit 406 and odd numbered tasks assigned to processing unit 405. A graphics processing system may include multiple groups of processing units, each arranged to process a different workload of tasks.

[0084] Assigning a task to a processing unit may include adding the task to a queue of tasks for processing by the processing unit.

[0085] 5 has the advantage of ensuring that at least two different processing units process each safety task, which avoids the possibility of repeated processing of a given task on the same processing unit, making it possible to detect excessive events as well as permanent faults on the processing units.

[0086] Repeated workload with readback While the approach described herein with respect to Figures 4 and 5 allows faults to be detected at the processing unit of a graphics processing system, it does not provide protection across the hardware on the data path after the processing unit. For example, faults introduced in the cache 206 or memory 201 are not identified. Data correction mechanisms such as error correction code (ECC) can provide some ability to recover from minor cache and memory errors such as single bit flipping. Error detection mechanisms such as parity bits may be used in caches and / or memories. However, such mechanisms cover data but do not control messages communicated to / from the GPU.

[0087] It may be advantageous to perform checks of the processed task data on the data path following one or more caches and / or memories to which the processed task data is written (e.g., for use in a process implemented in a GPU-supported data processing system). This allows for verification of the contents of the caches and / or memories to help ensure that the processed task data available (e.g., in a data processing system including a GPU) is the same valid processed data generated by the processing unit.

[0088] One embodiment of an arrangement for checking caches and memories is shown diagrammatically in Figure 6 and will be described again with reference to the flow chart shown in Figure 8. In Figures 6(a) and 6(b), the first and second processing passes of a task are shown to be performed in the same manner as described in relation to Figures 5(a) and 5(b). The first and second processing passes of a task may be performed in the same manner as described in relation to Figures 4(a) and 4(b). More generally, the processing of a task and the checking of outputs from a processing unit of a GPU may be performed according to any of the principles described herein.

[0089] 6(c) shows diagrammatically the readback checks performed on the processed task data written out to memory 201. In the figure, the processed task data written out 710 to memory 201 is read back 605, 711 from memory 201 into cache 206. In general, the processed task data for each safety task may be read back to any data store accessible to check unit 208 or may be streamed directly to check unit 208. The processed task data read back from memory 201 to cache 206 is operated on by check unit 208 to form 712 a signature 603 that is characteristic of the processed task data. The check unit is configured to store 713 in data store 209 one or both of the signatures 403, 404 formed for the output of processing units 405 and 406 for each task. The instance of the check unit 208 configured to form a signature of the processed task data read back from memory may be a different instance than the instance of the check unit 208 configured to form a signature for each pass of the task through the processing unit. In some embodiments, the same check unit instance is used to minimize the size of the GPU. In other embodiments, different check unit instances are used to maximize the fault detection capabilities of the system.

[0090] In general, the check unit may be configured to store for each safety task one or more of the signatures of the outputs of the processing units arranged to process that task. If the signature characteristics of the outputs from the processing units arranged to process the safety task match, only one of the signatures may be saved to avoid unnecessary storage of duplicate data. If the signature characteristics of the outputs from the processing units arranged to process the safety task do not match, the signature may not be stored. For example, if the signatures do not match, the signatures may be discarded and the processed task data may be discarded. This avoids consuming memory bandwidth in unnecessary writing out of invalid processed task data.

[0091] In the embodiment shown in FIG. 6(c), the fault detection unit 210 is configured to compare 714 the signature 603 formed for the processed task data read back from the memory with the stored signature 403 / 404 characteristics of the processed task data at the point of output from the processing unit. The processed data corresponding to a particular task may be identified in any suitable manner. For example, each task may be associated with an identifier, and the same identifier may be associated with each processed task output by the processing unit. The same identifier may be associated with each signature formed for the processed task for the same task. In this manner, the tasks, processed tasks, and signatures may be easily identified in the graphics processing system. In other embodiments, the tasks, processed tasks, and their signatures may use any combination of two or more different identifiers, and a data structure (e.g., a look-up table) may be provided that identifies the correspondence between the tasks, the processed task data for those tasks, and the signatures for the processed tasks.

[0092] If the signatures 603 and 403 / 404 do not match 708, the fault detection unit 210 is configured to generate a fault signal 604. The fault signal 604 may have any of the characteristics of the fault signal 211 described herein with reference to Figures 4 and 5. The fault signal 604 may or may not be different from the fault signal 211. The fault signal 604 may be generated in association with a particular task, for example, the fault signal may identify which task the fault is associated with. The data processing system in which the GPU 200 is provided may use the fault signal in any manner appropriate for the application. For example, upon receiving a fault signal in association with a task, the data processing system may cause all processed data associated with the task to be flushed from the memory 201 and / or cache 206. The data processing system may cause the task to be resubmitted to the processor. Such resubmitted tasks may be assigned a high priority to be processed by the GPU as much as possible.

[0093] In some embodiments, memory fault checking may be performed outside of the GPU, and the checking unit 208 may be configured to make available at least a portion of the signature that the GPU generates for the processed task to a supported system. For example, FIG. 7 illustrates an arrangement in which fault checking is performed in software. In the system illustrated in FIG. 7, the first and second passes may be performed as in the system illustrated in FIG. 6, according to any of the principles described herein. FIG. 7(b) further illustrates how software fault checking may be performed. The software checking unit 601 is configured to read back 605, 711 the processed task data from the memory 201, and form 712 a signature 603 characteristic of the processed data. The software checking unit 601 is configured to perform the same checking calculations as the checking unit 208, thereby enabling a comparison of the signature it generates with the signature formed by the checking unit 208.

[0094] The check unit 208 is configured to utilize 606 signatures stored in the data store 209 formed for tasks processed in the first and second passes through the processing unit 204. For example, the check unit may write the signatures to the memory 201. The signature formed in relation to a given task may be written to the memory in response to the fault detection unit determining that the outputs from the processing unit(s) configured to process that task during different passes match. The signature formed for a given task may be written to the memory along with the processed data itself. In general, the graphics processing system is configured to utilize 713, for each safety task, at least one of the signatures formed by the check unit of the output(s) of the processing unit(s) based on the processing of that task. The signatures may be made available in any suitable manner (e.g., by storing the signatures in a data store on the GPU accessible to software, by one or more of the signatures being written to memory, by writing the signatures to a data store external to the GPU).

[0095] The software fault detection unit 602 is configured to compare 714 one or more of the signature(s) (e.g., 403, 404) available to the checking unit 208 with the signature 603 formed by the software checking unit 601. If the signatures do not match 708, a fault signal 604 is generated, indicating data corruption at some point on the data path between the output of the processing unit and the output of the memory, including the cache 206 and memory 201. The fault signal 604 may have any of the characteristics of the fault signal 211 described herein with reference to Figures 4, 5 and 6.

[0096] The software checking unit 601 may be supported in any suitable software environment, including, for example, the software environment of a data processing system in which the GPU is supported (e.g., software environment 301 in data processing system 300 of FIG. 3) and / or a software environment provided by the GPU itself. The software checking unit may be provided, for example, in one or more of a driver of the GPU (e.g., 309 of FIG. 3), an operating system (e.g., 306 of FIG. 3), and a process (e.g., 307 of FIG. 3). The software checking unit 601 may be provided in any combination of software and / or firmware.

[0097] In general, the checking unit configured to form a signature of the processed task data read from the memory and / or the fault detection unit that compares the signature with a corresponding signature generated in the GPU for a given task may be located anywhere in the graphics processing system (e.g., in the GPU or in a data processing system in which a GPU is supported). For example, the checking unit and / or the fault detection unit may be provided in hardware in the data processing system and may be arranged to receive the processed task data from the memory 201 and the signature from the GPU.

[0098] Arranging for the processed task data to be read back from memory consumes memory bandwidth, but additionally allows the graphics processing system to achieve a higher level of safety by being able to detect faults in the memory and in some preceding caches on the data path from the GPU to the memory.

[0099] Asymmetric approach As mentioned above, in some embodiments, the processed task data generated in a first pass of the safety task through the GPU is written to memory 201 and the processed task data of the first pass is read back to a check unit (e.g., check unit 208 or software check unit 601) for formation of its respective signature 603. Since the processed task data generated in the first pass is generally available first, this allows a signature to be available as soon as possible for the processed task data held in memory. A second processing pass of the task through the GPU may overlap the time when the processed task data from the first pass is written to memory and / or the time when the processed task data from the first pass is read back from memory and / or the time when a signature is formed for the processed task data from the first pass.

[0100] Further, the graphics processing system may be configured not to form a signature on the processed task data from a first pass before that data is written out to memory. This is illustrated in FIG. 9 and shown in the flow chart of FIG. 11. A safety task is received for processing at the graphics processing system 901. Upon executing a first pass of the safety task 902 at a processing unit (e.g., task T0 is processed at processing unit 405 in FIG. 9(a)), the check unit 208 is arranged not to form a signature on the processed data output by that processing unit for that task at that time. Instead, the processed task data from the first pass is written out 903 to memory 201 via cache 206. When the task is processed at the GPU a second time 906 (e.g., task T0 is processed in a second pass at processing unit 406 in FIG. 9(b)), a signature 404 is generated 907 at the check unit 208 according to any of the principles described herein with respect to FIGS. 2-7. The signatures 404 from subsequent passes may be stored 908 in the data store 209. Because a signature may not yet be available for the first pass, no ongoing comparison is shown in FIG. 9(b) and no fault signal is generated.

[0101] To minimize the bandwidth consumed between the GPU and memory, the processed task data for the second pass may not be written to memory. The signature of the second pass may be formed before the processed task data of the second pass is written to the cache. In some implementations, to minimize the size of the required cache, if the processed task data for the second pass is not written to the cache, it (writing the processed task data for the second pass to the cache) may be unnecessary if the processed data is not written to memory.

[0102] The processed task data from the first pass is read back from memory for further checks to be performed 904. This process is illustrated in Figure 9(c) where the processed task data is read back 605 for a signature to be formed 905 in check unit 208. In the embodiment shown in Figure 9(c) the processed data is read back to cache 206, but in general the read back may be to any data store of the GPU and / or may be streamed to check unit 208 without non-transient storage of the processed data to the GPU's data store. Check unit 208 is configured to receive the read back processed task data from the first pass and generate a signature 603 that is characteristic of that data. Because processed task data is written out to memory 201 and read back before receipt at the check unit, signature 603 captures not only faults that occur in the processing of the task at the processing unit performing the first pass, but also faults that occur in memory 201, cache 206, and along the data paths to / from those data stores (e.g., via the interconnect between GPU 200 and memory 201).

[0103] The fault detection unit 210 is configured to compare 909 the signature 404 characteristics of the second pass of the task through the GPU with the signature 603 characteristics of the first pass of the task through the GPU and as stored in the memory 201. If the two signatures do not match 911, the fault detection unit 210 may generate a fault signal 604. The signatures do not match if the outputs of the two processing units are different and / or if data corruption has occurred in or between the caches and / or memories. Thus, the fault signal 604 is representative of faults in both the processing units of the GPU and the caches and / or memories. If the two signatures match 912, the processed task data generated in the first pass and available in the memory 201 may be considered valid and may be used in a manner appropriate to the application (e.g., in an automotive context, the processed task data may represent graphics data for writing to an instrument console).

[0104] In the embodiment shown in FIG. 9(c), fault checking of the processed data read back from the memory 201 is performed in the GPU. In other embodiments, fault checking of the memory may be performed in a further check unit external to the GPU, and the check unit 208 may be configured to make available to the further check unit a signature formed on the processed data from the second pass. The check unit for receiving the read back of the processed data from the memory may be arranged according to any of the methods described herein with respect to FIG. 6 and FIG. 7. For example, a software check unit may be provided in the manner shown in FIG. 7, and the GPU 200 may be configured to provide the signature 404 from the second pass to the software check unit, where the software check unit is configured to generate a fault signal 604 if the signature from the second pass does not match the signature of the processed data read back of the first pass from the memory. If fault checking is performed external to the GPU, the GPU may not include a fault detection unit 210 and may not generate a fault signal. 9 is schematic, and the GPU may not include a data store for holding the signatures generated by the check unit 208. For example, the check unit may be configured to write out to memory the signatures generated for each second pass of a task processed by the GPU.

[0105] The asymmetric approach of forming a signature in a second pass over the output from each processing unit while forming a signature in a first pass over the output from each processing unit and the memory to which that output is written has several advantages. First, only two signatures need to be formed to capture faults in both the processing units and the memory. This reduces the processing required on the GPU (and potentially other systems), reduces the power consumption of the GPU, and reduces the size of the data storage required on the GPU to store the signatures formed in the check units. Second, the asymmetric approach minimizes memory write bandwidth since only the first processed output from the GPU needs to be written to memory, and there is no need to write data to memory from the second pass. Third, the asymmetric approach minimizes the time until a fault signal is available since the processed output from the first pass can be written to memory as soon as it is available without having to wait for the results of the second pass to compare the signatures of the first and second passes and validate the output of the first pass.

[0106] In short, the asymmetric approach allows covering the maximum chip area (processing unit + cache + memory) at the minimum cost in terms of processing, power consumption and chip area.

[0107] In the embodiments shown in Figures 6, 7 and 9, the processed task data is read back from memory. In some embodiments, the processed task data may be read back from the cache to detect cache faults. This may be instead of or in addition to reading back the processed task data from memory. Reading back from the cache rather than from memory does not provide memory protection, but may have the advantage of avoiding bandwidth consumption between the GPU and memory. To minimize reads from the cache, the processed task data may be directed to the check unit 208 on the basis of being read from the cache 206 to the memory 201 such that both the memory 201 and the check unit 208 receive the processed task data.

[0108] By checking that the processed task data output by the processing unit is the same processed task data read from the memory and / or cache, a greater degree of protection against data faults may be provided. This may allow a higher level of safety to be achieved. When used in an automotive context, a graphics processing system configured according to the principles described herein may achieve at least ASIL level B. By combining the graphics processing system taught herein with traditional error recovery and fault detection mechanisms, ASIL level D may be achieved. For example, memory 201 and / or cache 206 may be ECC memory, which allows recovery from minor errors and improves the robustness of the graphics processing system against transient events.

[0109] A graphics processing system configured according to the principles described herein may be configured to process both safety tasks related to safety-critical functions and normal tasks not related to safety-critical functions. Because each task and each instance of a task may be assigned to a processing unit of the system independently of any other task or instance of a task (subject to some constraints that processing units may not be reused for the same task), the graphics processing system may redundantly process safety tasks that comply with a required safety level while processing normal tasks in a single pass without complying with that safety level. In some embodiments, a subset of the processing units of the graphics processing system is reserved for processing safety tasks such that safety tasks and normal tasks are processed on different processing units. The advantages described herein follow whether safety tasks and normal tasks are configured to be processed on different sets of processors. Compared to a lockstep processor coupled to process all tasks assigned at least twice, this approach reduces power consumption, reduces on-chip data bandwidth, and reduces the size of the GPU required to provide a given processing performance since it avoids wasting chip area to provide dedicated safety cores when safety cores are not necessarily required.

[0110] The graphics processing system and data processing system of Figures 2-7, 9 and 10 are shown as including a number of functional blocks. This is schematic only and is not intended to define a strict division between different logical elements of such entities. Each functional block may be provided in any suitable manner. It will be understood that intermediate values ​​described herein as being formed by the graphics processing system need not be physically generated by the graphics processing system at any point, but may simply represent logical values ​​that conveniently describe the processing performed by the graphics processing system between its inputs and outputs.

[0111] The graphics processing units described herein may be embodied in hardware on an integrated circuit. The graphics processing systems described herein may be configured to perform any of the methods described herein.

[0112] The terms computer program code and computer readable instructions, as used herein, refer to any kind of executable code for a processor, including code expressed in a machine language, an interpreted language, or a scripting language. Executable code includes binary code, machine code, bytecode, code defining an integrated circuit (such as a hardware description language or netlist), and code expressed in a programming language code such as C, Java, or OpenCL. Executable code may be any type of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, or executed, for example, in a virtual machine or other software environment, causes a processor of a computer system in which the executable code is supported to perform the tasks specified in the code. Examples of computer readable storage media include random access memory (RAM), read only memory (ROM), optical disks, flash memory, hard disk memory, and other memory devices that can store instructions or other data and be accessed by a machine using magnetic, optical, and other technologies.

[0113] A processor, computer, or computer system may be any type of device, machine, or special-purpose circuitry, or a collection or portion thereof, having processing capability such that instructions can be executed. A processor may be any type of general-purpose or special-purpose processor, such as, for example, a CPU, GPU, vector processor, tensor processor, system on a chip, state machine, media processor, application specific integrated circuit (ASIC), programmable logic array, field programmable gate array (FPGA), etc. A computer or computer system may include one or more processors.

[0114] It is also intended to include software that defines a configuration of hardware as described herein, such as HDL (Hardware Description Language) software, to be used to design an integrated circuit or configure a programmable chip to perform a desired function. That is, a computer-readable storage medium may be provided having encoded thereon computer-readable program code in the form of an integrated circuit definition data set that, when processed in an integrated circuit manufacturing system, configures the system to manufacture a graphics processing unit configured to perform any of the methods described herein or to manufacture a graphics processing unit that includes several of the devices described herein. The integrated circuit definition data set may be, for example, a description of an integrated circuit.

[0115] An integrated circuit manufacturing system may be provided with a method for manufacturing a graphics processing unit as described herein. An integrated circuit definition data set may be provided that, when processed by the integrated circuit manufacturing system, causes the method for manufacturing a graphics processing unit to be performed.

[0116] The integrated circuit definition data set may be in the form of computer code, for example as a netlist, code for configuring a programmable chip, register transfer level (RTL) code, a high level circuit representation such as Verilog or VHDL, or a low level circuit representation such as OASIS (RTM) or GDSII, that defines the integrated circuit at any level. A high level representation that logically defines the integrated circuit (such as RTL) may be processed by a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining those elements to generate a manufacturing definition of the integrated circuit as so defined by the representation. In general, as is the case with software implemented on a computer system to define a machine, a computer system configured to generate a manufacturing definition of an integrated circuit may require one or more intermediate user steps (e.g., providing commands, variables, etc.) to execute the code that defines the integrated circuit to generate a manufacturing definition of the integrated circuit.

[0117] An embodiment of processing an integrated circuit definition data set in an integrated circuit manufacturing system to configure the system to manufacture a graphics processing unit will now be described with reference to FIG.

[0118] 10 illustrates an example of an integrated circuit (IC) manufacturing system 1002 configured to manufacture a graphics processing unit as described in any of the embodiments herein. In particular, the IC manufacturing system 1002 includes a layout processing system 1004 and an integrated circuit generation system 1006. The IC manufacturing system 1002 is configured to receive an IC definition data set (e.g., defining a graphics processing unit as described in any of the embodiments herein), process the IC definition data set, and generate an IC according to the IC definition data set (e.g., embodying a graphics processing unit as described in any of the embodiments herein). The processing of the IC definition data set configures the IC manufacturing system 1002 to manufacture an integrated circuit embodying a graphics processing unit as described in any of the embodiments herein.

[0119] The layout processing system 1004 is configured to receive and process the IC definition data set to determine a circuit layout. Methods for determining a circuit layout from an IC definition data set are known in the art and may include synthesizing RTL code to determine a gate-level representation of the circuit to be generated, for example, in terms of logical components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining position information of the logical components, a circuit layout may be determined from the gate-level representation of the circuit. This may be done automatically or with user involvement to optimize the circuit layout. When the layout processing system 1004 has determined the circuit layout, it may output a circuit layout definition to the IC generation system 1006. The circuit layout definition may be, for example, a circuit layout description.

[0120] The IC generation system 1006 generates ICs according to the circuit layout definition, as known in the art. For example, the IC generation system 1006 can perform a semiconductor device manufacturing process to generate the IC, which may include a multi-step sequence of photolithography and chemical processing steps during which electronic circuits may be gradually generated on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask that may be used in a lithography process to generate an IC according to the circuit definition. Alternatively, the circuit layout definition provided to the IC generation system 1006 may be in the form of computer readable code that the IC generation system 1006 may use to form an appropriate mask for use in generating the IC.

[0121] The different processes performed by IC manufacturing system 1002 may all be implemented at one location, e.g., by one party. Alternatively, IC manufacturing system 1002 may be a distributed system such that parts of the processes may be performed at different locations and by different parties. For example, parts of (i) synthesizing RTL code representing an IC definition dataset to form a gate-level representation of a circuit to be generated, (ii) generating a circuit layout based on the gate-level representation, (iii) forming a mask according to the circuit layout, and (iv) manufacturing the integrated circuit using the mask may be performed at different locations and / or by different parties.

[0122] In other examples, processing of the integrated circuit definition data set on an integrated circuit manufacturing system may configure the system for manufacturing a graphics processing unit without the IC definition data set being processed to determine a circuit layout. For example, the integrated circuit definition data set may define a configuration of a reconfigurable processor such as an FPGA, and processing of that data set may configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration (e.g., by loading configuration data into the FPGA).

[0123] In some embodiments, the integrated circuit manufacturing definition dataset, when processed by an integrated circuit manufacturing system, may cause the integrated circuit manufacturing system to generate a device as described herein. For example, configuration of an integrated circuit manufacturing system with the integrated circuit manufacturing definition dataset in the manner described above with respect to FIG. 10 may cause a device as described herein to be manufactured.

[0124] In some embodiments, the integrated circuit definition data set may include software that executes on or in combination with hardware defined in the data set. In the embodiment shown in Figure 10, the IC generation system may be further configured by the integrated circuit definition data set to load firmware into the integrated circuit in accordance with the program code defined in the integrated circuit definition data set when manufacturing the integrated circuit, or to otherwise provide the program code to the integrated circuit for use with the integrated circuit.

[0125] Implementation of the concepts described in this application in devices, apparatus, modules, and / or systems (as well as methods implemented herein) may result in improved performance when compared to known implementations. The improved performance may include one or more of increased computational performance, reduced latency, improved throughput, and / or reduced power consumption. During the manufacture of such devices, apparatus, modules, and systems (e.g., in integrated circuits), performance improvements may be traded off against physical implementation, thereby improving manufacturing methods. For example, performance improvements may be traded off against layout area, thereby matching the performance of known implementations but using less silicon. This may be done, for example, by serializing and reusing functional blocks or sharing functional blocks between elements of the devices, apparatus, modules, and / or systems. Conversely, concepts described in this application that result in improved physical implementation of devices, apparatus, modules, and systems (such as reduced silicon area) may be traded off for improved performance. This may be done, for example, by manufacturing multiple instances of a module within a given area budget.

[0126] Applicant hereby discloses each individual feature described herein and any combination of two or more such features alone to the extent that such feature or combination can be implemented in accordance with the present specification as a whole in light of the common general knowledge of those skilled in the art, regardless of whether such feature or combination of features solves any problems disclosed herein. In view of the foregoing description, it will be apparent to those skilled in the art that various modifications can be made within the scope of the present invention.

Claims

1. A data store; one or more processing units for processing tasks; at least one checking unit operable to form a signature characteristic of an output from the processing of a task in the processing unit; a fault detection unit operable to compare the signatures formed by the at least one checking unit; Equipped with Operable to process at a first time and a second time to generate a first processed output and a second processed output, respectively, in the one or more processing units; writing the first processed output to the data store; reading back the first processed output from the data store and forming, in the at least one checking unit, a first signature that is characteristic of the first processed output read back from the data store; forming, in the at least one checking unit, a second signature that is characteristic of a second processed output from the processing unit; comparing the first signature and the second signature in the fault detection unit; generating a fault signal if the first signature and the second signature do not match; Graphics processing system.

2. configured to write the first processed output to the data store without waiting for the second processed output to be available.

2. The graphics processing system of claim 1.

3. the at least one checking unit does not form a signature for the first processed output before the first processed output is written to the data store.

3. A graphics processing system according to claim 1 or 2.

4. not writing the second processed output to the data store; 3. A graphics processing system according to claim 1 or 2.

5. the one or more processing units, the at least one checking unit and the fault detection unit are provided in a graphics processing unit; the data store comprises a memory external to the graphics processing unit; writing the first processed output to the memory of the data store; 3. A graphics processing system according to claim 1 or 2.

6. the one or more processing units and the second instance of the at least one checking unit are disposed in a graphics processing unit; the first instance of the at least one checking unit, the fault detection unit and the data store memory are external to the graphics processing unit; writing the first processed result to the data store by writing the first processed result to the memory; reading back the first processed result from the data store to form the first signature by reading back the first processed result from the memory, and forming, in the first instance, a first signature characteristic of the first processed output read back from the memory; forming the second signature by forming a second signature characteristic of the second processed output from a processing unit at the second instance; making the second signature available to the fault detection unit; 3. A graphics processing system according to claim 1 or 2.

7. the first instance is provided in software of a data processing system in which the graphics processing unit is supported; 7. A graphics processing system according to claim 6.

8. the data store comprises one or more memories internal or external to the graphics processing unit, and / or one or more caches internal or external to the graphics processing unit; 3. A graphics processing system according to claim 1 or 2.

9. a first processing unit of the one or more processing units processes the task at the first time of processing; a second processing unit of the one or more processing units processes the task at the second time of the process; 3. A graphics processing system according to claim 1 or 2.

10. the second processing unit receives the task independently of the first processing unit; 10. The graphics processing system of claim 9.

11. the second processing unit is constrained to a processing unit of the one or more processing units other than the first processing unit; 10. The graphics processing system of claim 9.

12. The first processing unit and the second processing unit are allowed to be the same processing unit.

10. The graphics processing system of claim 9.

13. a plurality of processing units; each processing unit processes a task independently of any other processing unit of the plurality of processing units; 3. A graphics processing system according to claim 1 or 2.

14. Each task includes an identifier indicating whether the task is a safety task that is processed according to a predefined safety level; 3. A graphics processing system according to claim 1 or 2.

15. 1. A method of processing tasks in a graphics processing system having a plurality of processing units, each processing unit processing tasks independently of the other processing units, comprising the steps of: processing the task at a first time with a first processing unit to generate a first processed output; writing the first processed output to a data store; reading back the first processed output from the data store and forming a first signature that is characteristic of the first processed output read back from the data store; processing the task at a second time with a second processing unit to generate a second processed output and forming a second signature that is characteristic of the second processed output output from the second processing unit; comparing the first signature and the second signature; generating a fault signal if the first signature and the second signature do not match; A method comprising:

Images