Key workload checks

Abstract

The present disclosure relates to critical workload checking. A method of initializing rendering at a graphics processing unit configured to perform safety critical rendering within a graphics processing system, the method comprising: generating configuration data for initializing safety critical graphics data rendering at the graphics processing unit; receiving the configuration data for initializing rendering at the graphics processing unit; configuring the graphics processing unit in accordance with the configuration data for initializing rendering; determining whether the graphics processing unit is correctly configured in accordance with the configuration data; and in response to determining that the graphics processing unit is not correctly configured in accordance with the configuration data, determining, by a safety controller external to the graphics processing unit, that an initialization error has occurred.

Description

Technical Field

[0001] This disclosure relates to methods and graphics processing systems for initializing safety-critical rendering. Background Technology

[0002] In safety-critical systems, at least some components must meet safety objectives sufficient to enable the system as a whole to meet the level of safety considered necessary for the system. For example, in most jurisdictions, seatbelt retractors in vehicles must meet specific safety standards so that vehicles equipped with such devices can pass safety tests. Similarly, vehicle tires must meet specific standards so that vehicles equipped with such tires can pass safety tests appropriate for a particular jurisdiction. Safety-critical systems are typically those whose failure would significantly increase the risk to human safety or the environment.

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

[0004] Increasingly, data processing devices used in safety-critical systems include processors running software. Both hardware and software components must meet specific safety objectives. Some software failures may be systematic failures caused by programming errors or poor error handling. These problems can usually be addressed through rigorous development practices, code reviews, and testing protocols. Even if a safety-critical system may not contain any systematic errors, random errors can still be introduced into the hardware, for example, due to transient events such as ionizing radiation, voltage spikes, or electromagnetic pulses. In binary systems, transient events can cause random bit flips in memory and along the processor's data path. Hardware may also have permanent failures.

[0005] The security objectives of a data processing device can be expressed as a set of metrics, such as the maximum number of failures within a given time period (typically expressed as Failure-to-Time or FIT), and the effectiveness of mechanisms for detecting single points of failure (Single Point Failure Mechanism or SPFM) and for detecting potential failures (Least Point Failure Mechanism or LFM). Various methods exist for achieving the security objectives set for the data processing device: for example, by providing hardware redundancy so that if one component fails, another can be used to perform the same task, or by using check data (e.g., parity bits or error correction codes) to enable the hardware to detect and / or correct minor data corruption.

[0006] For example, the data processor can be configured with a double-lockstep arrangement of 100, such as... Figure 1 As shown, a pair of identical processing cores 101 and 102 are configured to process a series of instructions 103 in parallel. The output of either processing core (101) can be used as the output 104 of the lockstep processor. When the outputs of processing cores 101 and 102 do not match, a fault can be triggered in a safety-critical system. A delay 105 can be introduced at the input of one core to improve the probability of detecting errors caused by external factors such as ionizing radiation and voltage spikes (where a corresponding delay 106 is typically provided at the output of the other core). However, dual lockstep processors are expensive because a second processing core is required, as they must consume twice the chip area and consume approximately twice the power compared to conventional processors.

[0007] Advanced driver assistance systems (ADAS) and autonomous vehicles can incorporate data processing systems suitable for such safety-critical applications with significant graphics and / or vector processing capabilities. However, the increased area and power consumption (and therefore cost) of implementing a dual-lockstep processor may be unacceptable or undesirable. For example, driver assistance systems often provide computer-generated graphics that show the driver hazards, lane positions, and other information. This typically leads vehicle manufacturers to replace conventional dashboards with computer-generated ones, meaning that the display of safety-critical information such as speed and vehicle malfunction information becomes computer-generated. Such processing requirements can be met by a graphics processing unit (GPU). However, in an automotive context, ADAS typically require data processing systems that meet ISO 26262 ASIL Level B.

[0008] For example, in an automotive environment, a graphics processing system can be used to render instrument clusters for display on a dashboard screen. The instrument clusters provide the driver with critical information, such as vehicle speed and details of any vehicle malfunctions. It is important that this critical information be presented reliably to the driver, and vehicle regulations typically require that critical information be rendered in a manner consistent with predefined safety levels, such as ASIL B of the ISO 26262 standard.

[0009] Figure 2 Instrument cluster 200 is shown. The instrument cluster includes a speedometer 202 in a conventional dial format, with speed values ​​208 around the edge of the dial and a pointer 207 whose angle indicates the vehicle's current speed. The instrument cluster also includes an oil temperature gauge 203, information icons 204 (e.g., indicating the selected radio station), non-serious warning icons 205 (e.g., indicating a malfunction in the air conditioning system), and serious warning icons 206 (e.g., indicating a serious engine problem). It may be necessary to render the instrument cluster 200 in a manner that meets mandatory safety levels (e.g., ASIL B of the ISO 26262 standard).

[0010] In addition, autonomous vehicles must process large amounts of data in real time (such as data from radar, lidar, map data, and vehicle information) in order to make safety-critical decisions. Graphics processing units can also help meet these processing needs, but safety-critical systems in autonomous vehicles are typically required to meet the most stringent ASIL level D of ISO 26262. Summary of the Invention

[0011] This summary is provided to introduce some concepts that are further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0012] According to a first aspect of the present invention, a method for initializing rendering at a graphics processing unit configured to perform safety-critical rendering within a graphics processing system is provided. The method includes: generating configuration data for initializing safety-critical graphics data rendering at the graphics processing unit; receiving the configuration data for initializing rendering at the graphics processing unit; configuring the graphics processing unit according to the configuration data for initializing rendering; determining whether the graphics processing unit is correctly configured according to the configuration data; and, in response to determining that the graphics processing unit is not correctly configured according to the configuration data, determining by a safety controller external to the graphics processing unit that an initialization error has occurred.

[0013] The safety controller can reset the graphics processing unit in response to determining that an initialization error has occurred.

[0014] The method may further include continuing to render safety-critical graphics data at the graphics processing unit in response to determining that the graphics processing unit is correctly configured according to the configuration data.

[0015] The configuration data may include one or more register entries to be written to the graphics processing unit, specifying the configuration to be adopted by the graphics processing unit.

[0016] The generation of configuration data can be performed by the security controller.

[0017] Configuring the graphics processing unit according to the configuration data may include one of the following: the security controller writes one or more register entries into one or more registers; or the firmware of the graphics processing unit writes one or more register entries into one or more registers.

[0018] Determining whether the graphics processing unit has been correctly configured according to the configuration data may include: after configuring the graphics processing unit, reading back one or more register entries corresponding to the configuration data from each of the one or more registers of the graphics processing unit; and comparing one or more register entries read back from each register with the expected data entries of the registers specified by the configuration data.

[0019] Determining whether the graphics processing unit has been correctly configured according to the configuration data may include: after configuring the graphics processing unit, storing a snapshot of the one or more register entries corresponding to the configuration data in one or more registers of the graphics processing unit; and comparing one or more register entries in the snapshot of each register with the expected data entries of the registers specified by the configuration data.

[0020] Determining whether the graphics processing unit has been correctly configured according to the configuration data may include: after configuring the graphics processing unit, reading back one or more register entries corresponding to the configuration data from each of the one or more registers of the graphics processing unit; performing a checksum on the one or more register entries read back from the one or more registers; performing a checksum on the configuration data; and comparing the result of the checksum.

[0021] Determining whether the graphics processing unit has been correctly configured according to the configuration data may include: after configuring the graphics processing unit, storing a snapshot of the one or more register entries corresponding to the configuration data in one or more registers of the graphics processing unit; performing a checksum on the one or more register entries in the snapshot read back from the one or more registers; performing a checksum on the configuration data; and comparing the result of the checksum.

[0022] The check can depend on the location of one or more register entries within one or more registers.

[0023] The method may further include: causing instructions for initializing the rendering of safety-critical graphics data at the graphics processing unit to be written into the graphics processing unit, the instructions including a request for a response from the graphics processing unit; initializing a first timer configured to expire after a first time period; and monitoring responses from the graphics processing unit during the first time period; and if no response is received from the graphics processing unit before the first timer expires, the safety controller determines that an initialization error has occurred.

[0024] Instructions for initializing the rendering of safety-critical graphics data may include the configuration data, and the instructions request the graphics processing unit to respond after determining whether the graphics processing unit has been correctly configured according to the configuration data.

[0025] The time period can be determined based on the safety-critical graphic data to be rendered.

[0026] The method may further include: initializing a second timer configured to expire after a second time period shorter than the first time period; and monitoring responses from the graphics processing unit during the second time period; wherein the security controller is configured to reduce the workload of the graphics processing unit if the following conditions are met: no response is received from the graphics processing unit before the second timer expires; a response is received from the graphics processing unit before the first timer expires; and determining that the graphics processing unit has been correctly configured according to the configuration data.

[0027] According to a second aspect of the present invention, a graphics processing system is provided, comprising: a graphics processing unit for performing safety-critical rendering, the graphics processing unit being configurable according to configuration data for initializing the rendering; a host data processing system configured to generate configuration data for initializing safety-critical graphics data rendering at the graphics processing unit, and causing the graphics processing unit to be configured according to the configuration data for initializing the rendering; and a safety controller external to the graphics processing unit, the safety controller being arranged to: determine, based on the configuration data, whether the graphics processing unit is correctly configured; and, in response to determining that the graphics processing unit is not correctly configured according to the configuration data, determine that an initialization error has occurred.

[0028] The safety controller can reset the graphics processing unit in response to determining that an initialization error has occurred.

[0029] The graphics processing unit can be configured to continue rendering safety-critical graphics data in response to the security controller determining that the graphics processing unit is correctly configured according to the configuration data.

[0030] The graphics processing system can be embodied in hardware on an integrated circuit. A method for manufacturing the graphics processing system at an integrated circuit manufacturing system can be provided. An integrated circuit definition dataset can be provided, which, when processed in the integrated circuit manufacturing system, configures the system to manufacture the graphics processing system. A non-transitory computer-readable storage medium can be provided, on which a computer-readable description of an integrated circuit is stored, which, when processed in the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture the graphics processing system.

[0031] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium storing a computer-readable integrated circuit description describing the graphics processing system; a layout processing system configured to process the integrated circuit description to generate a circuit layout description of the integrated circuit embodying the graphics processing system; and an integrated circuit generation system configured to manufacture the graphics processing system according to the circuit layout description.

[0032] Computer program code for performing the methods described herein may be provided. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon may be provided, which, when executed at a computer system, cause the computer system to perform the methods described herein. Attached Figure Description

[0033] The invention is described by way of example with reference to the accompanying drawings. In the drawings:

[0034] Figure 1 This is a schematic diagram of a conventional double-lockstep processor.

[0035] Figure 2 The computer-generated vehicle instrument cluster is shown.

[0036] Figure 3 This is a schematic diagram of a graphics processing system that operates according to the principles described in this article.

[0037] Figure 4 This is a flowchart of a method for initializing safety-critical rendering at the graphics processing unit within a graphics processing system, based on the principles described in this article.

[0038] Figure 5 This is a flowchart of another method for initializing safety-critical rendering at the graphics processing unit within a graphics processing system, based on the principles described in this article.

[0039] Figure 6 This is a flowchart of another method for initializing safety-critical rendering at the graphics processing unit within a graphics processing system, based on the principles described in this article.

[0040] Figure 7 This is a schematic diagram of an integrated circuit manufacturing system. Detailed Implementation

[0041] The following description is given 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 readily apparent to those skilled in the art. Embodiments are described by way of example only.

[0042] This disclosure relates to methods and graphics processing systems for initializing safety-critical rendering.

[0043] Graphics Processing System 300 Figure 3 As shown in the diagram. The graphics processing system 300 includes at least one graphics processing unit (GPU) 312. The GPU 312 may be suitable for rendering. Figure 2 The instrument cluster 200 is shown. The GPU 312 may include hardware components (e.g., hardware processing units) and software components (e.g., firmware, and programs and tasks executed at the hardware processing unit). The operation and arrangement of the GPU units will vary depending on the specific architecture of the GPU.

[0044] GPU 312 may include one or more processing units 339, which in Figure 3The units are labeled PU0, PU1, and PU(n). GPU 312 can have any number of processing units. GPU 312 may also include firmware 314. Firmware 314 can be embodied as software, hardware, or any combination of software and hardware. For example, firmware 314 can be software executed using hardware processing logic. Firmware 314 can, for example, perform low-level management of the GPU and provide an interface for instructions directed to the GPU. In some arrangements, GPU 312 may be configured to execute software in the form of functions, routines, and other code arranged to execute at units of the GPU (e.g., its processing unit 339 and / or firmware 314).

[0045] GPU 312 may also include a register library 350, which includes one or more registers. Register library 350 is accessible by processing units 339. Data for the processing units 339 may be stored within register library 350 and read by these processing units 339. The data may include data to be processed by the processing units 339, and / or configuration data specifying what will be adopted by the processing units 339. For example, the configuration may determine how one of the processing units 339 processes data, such as during the rendering of graphics data. Register library 350 may be populated and managed by firmware 314. That is, firmware 314 may have permission to read from and write to one or more registers in register library 350. GPU 312 may also include any other form of memory (not shown). The memory may include any type of memory, such as a cache or buffer.

[0046] GPU 312 may also include a reset unit 351 configured to cause a reset of GPU 312 (e.g., a hardware recovery reset). A reset may include returning some or all of the GPU triggers to a known safe state, and / or invalidating some or all of the data stored in memory such as register bank 350 within GPU 312. A reset may eliminate certain errors, such as those that cause GPU failure. A reset may be indicated by GPU 312 itself. Alternatively, the reset may be caused by a command 336 sent from an external entity such as host data processing system 302.

[0047] GPU 312 may include various other functional elements, such as those for processing data, communicating with external devices such as host data processing system 302, and supporting processing performed at one or more processing units 339.

[0048] The graphics processing system 300 may also include a driver 304 for the GPU 312. For example, the driver 304 may be a software driver. The driver 304 can provide an interface to the GPU 312 for processes (e.g., software applications) running at the data processing system. Figure 3In the example shown, the graphics processing system 300 includes a host data processing system 302. One or more processes 301 can run on the host data processing system 302. These processes 301... Figure 3 The processes are labeled A0, A1, and A(n). Any number of processes 301 can run on the host data processing system 302. One or more processes 301 can interact with the GPU 312 330 via driver 304. The host data processing system 302 may include one or more processors (e.g., CPU – not shown) where processes 301 and driver 304 are executed. A graphics application programming interface (API) 303 (e.g., OpenGL) may be provided at driver 304, which process 301 can use to submit rendering calls. Driver 304 may be a software component of the host data processing system 302.

[0049] API 303 may be configured to receive draw calls from process 301 to cause GPU 312 to render the scene. For example, the API may be an OpenGL API, and the process may be configured to issue OpenGL draw calls to cause the GPU to render the scene. Figure 2 The instrument cluster shown is rendered onto the display screen on the vehicle's dashboard. Driver 304 also includes a safety controller 311, which will be discussed in further detail herein.

[0050] exist Figure 3 In the depicted example, driver 304 generates commands and / or control instructions to cause GPU 312 to execute draw calls submitted to API 303 via process 301. The instructions can pass data defining the scene to be rendered to GPU 312 in any suitable manner, such as as references to data in memory. Figure 3 As shown, the instruction 332 can be sent to one or more buffers 308 in memory 307. GPU 312 can read instruction 333 from memory 307. Memory 307 may be located at host data processing system 302. Memory 307 may also include a buffer 310 for receiving instructions returned from GPU 312. The buffer may be a circular buffer.

[0051] The graphics processing unit 312 can be, for example, any kind of graphics and / or vector and / or stream processing unit. The GPU 312 can include a rendering pipeline for performing geometry processing and / or fragment processing on the primitives of the scene. Each processing unit 339 can be a different physical core of the GPU.

[0052] The following examples are described with reference to tile-based rendering techniques; however, it should be understood that graphics processing systems may alternatively or additionally employ other rendering techniques, such as real-time rendering or hybrid techniques that combine elements of both tile-based and real-time rendering.

[0053] The graphics processing system 300 configured according to the principles described herein can have any tile-based architecture—for example, the system can be used to perform tile-based deferred rendering. Figure 3 Each processing unit 339 depicted in the diagram can process a tile independently of any other processing unit and independent of any other tile.

[0054] Tile-based rendering systems use a rendering space subdivided into multiple tiles. As is known in the art, tiles can have any suitable shape and size, such as rectangles (including squares) or hexagons. A tile in the rendering space can be associated with a portion of a rendering target, for example, representing a frame to be rendered at a graphics processing system. A frame can be all or part of an image or video frame. In some instances, the rendering output is not the final image to be displayed, but can represent something else, such as a texture, which is subsequently applied to a surface when rendering an image containing that texture. In the examples described below, the rendering output is a frame representing an image to be displayed; however, it should be understood that in other instances, the rendering output can represent other surfaces, such as textures or environment maps.

[0055] Tile-based rendering systems typically perform two distinct operational phases: (i) a geometry processing phase, where geometry (e.g., primitives) is processed for each tile in the rendering space to determine which geometric items are likely relevant to rendering the tile (e.g., which primitives at least partially overlap the tile); and (ii) a rendering phase (or “fragment processing phase”), where geometry relevant to rendering a particular tile is processed to render the tile—e.g., to generate pixel values ​​for pixel locations within the tile, which can then be output from the rendering system, for example, to be stored in a buffer (e.g., a frame buffer) and / or for display. Processing tile-related geometry may include, for example, generating primitive fragments by sampling primitives at sample locations on the tile, and determining which fragments are visible and how the fragments affect pixel appearance. A one-to-one relationship may exist between sample locations and pixels. Alternatively, more than one sample location may be associated with each pixel location, such that the final pixel value can be generated by combining the rendered values ​​determined for multiple sample locations. This can be used to implement anti-aliasing.

[0056] Graphics processing units (such as GPU 312) can be configured to perform some or all of any aspect of graphics processing during the geometry processing and rendering phases, including, for example, tile processing, geometry processing, texture mapping, shading, depth processing, vertex processing, tile acceleration, clipping, culling, primitive assembly, color processing, stencil processing, anti-aliasing, ray tracing, pixelation, and tessellation.

[0057] The geometry processing logic and the fragment processing logic can share the resources of a graphics processing unit (such as GPU 312). For example, a processing unit of the graphics processing unit (such as processing unit 339 of GPU 312) can be used to implement a portion of both the geometry processing logic and the fragment processing logic, for example, by executing different software instructions on the execution unit of the processing unit. The processing unit (such as processing unit 339) can be configured to perform SIMD processing.

[0058] The graphics processing system configured according to the principles described in this article can be set up to render any kind of scene.

[0059] return Figure 3 The graphics processing system 300, based on the principles described herein, includes at least one graphics processing unit (GPU) 312. The graphics processing system 300 also includes a security controller 311. The security controller 311 can be embodied in hardware (e.g., fixed-function hardware), software, or any combination thereof (e.g., as a software process running on general-purpose hardware). The security controller 311 can communicate with the GPU 312. The security controller 311 can communicate with the GPU 312 in any suitable manner. The security controller 311 can reside in any suitable location. In one instance, the security controller 311 and the GPU 312 can be part of the same system on a chip architecture. Figure 3 In the diagram, security controller 311 is shown as included in host data processing system 302. Security controller 311 may be a component of driver 304, which provides an interface to GPU 312 for process 301 (e.g., software application) running on host data processing system 302.

[0060] Safety controller 311 can be configured to cause a safety check to be performed on GPU 312. The safety check can be performed at any time. In one example, the safety check is performed when initializing graphics data rendering. For example, a safety check can be performed when GPU 312 is initialized to perform rendering of a graphics data frame. The frame may include data for safety-critical rendering. The safety check can be performed whenever GPU 312 is initialized to perform rendering of a safety-critical data frame, or on a subset of these occasions. In another example, a safety check can be performed when GPU 312 is initialized to perform rendering of tiles of graphics data. The tiles may include data for safety-critical rendering. The safety check can be performed each time GPU 312 is initialized to perform rendering of tiles of safety-critical data, or on a subset of these occasions. A safety check can also be performed when initializing geometry processing, fragment processing, or both geometry processing and fragment processing.

[0061] Figure 4 This is a flowchart 400 of a method for initializing safety-critical rendering at a graphics processing unit within a graphics processing system, based on the principles described herein.

[0062] A type of security check initiated by security controller 311 may involve verifying whether GPU 312 has been correctly configured to perform security-critical rendering. To perform this security check, configuration data 401 is generated for initializing security-critical graphics data rendering at the graphics processing unit.

[0063] When the configuration data is read by the processing unit 339 of GPU 312, the configuration data can cause the processing unit 339 to adopt a specific configuration. For example, the configuration data can configure the processing unit 339 to perform a specific processing task or a series of processing tasks on received data (e.g., graphics data). The configuration data can also instruct the processing unit 339 to retrieve the data to be processed from where (e.g., an address in memory 307), and / or how to process (e.g., store and / or report) intermediate data or final output generated during rendering.

[0064] Configuration data may include one or more register entries to be written to register library 350. The register entries may include register data. Configuration data may indicate a specific configuration for the register entries. For example, configuration data may specify that a particular register entry will be written to a particular register, and / or define a specific relationship between register entries to be written to each register within register library 350. In a simple example, configuration data may include register entries 1 through 10, which will be written to registers A through J (not shown) in ascending numerical order.

[0065] The safety controller 311 can generate one or more instructions that include the configuration data. These instructions can be sent to the GPU 312 via a buffer 308 in memory 307. Configuration data related to safety-critical rendering can bypass the queue in buffer 308, allowing it to be read into the GPU 312 more quickly.

[0066] Configuration data 402 is received at the graphics processing unit (e.g., GPU 312). For example, the configuration data may be contained within instructions read from memory 307 into GPU 312.

[0067] The graphics processing unit (e.g., GPU 312) configures itself according to the configuration data 403. In one example, the configuration data may be sent 333 to the firmware 314 of GPU 312, and the firmware 314 may be responsible for writing the configuration data into register bank 350. In another example, the security controller 311 may allow the configuration data to be written directly into register bank 350 335. In this example, the configuration data may also be sent 333 to the firmware 314 of GPU 312 (the reason for which is explained in the following paragraphs). Once the configuration data has been written into the registers, the graphics processing unit can be considered to be configured according to the configuration data. Once the configuration data is written into the registers, it can cause the GPU to operate in one or more different modes, cause different combinations of GPU components to be turned on or off, and / or cause any other changes to the configuration of the GPU.

[0068] Based on the principles described herein, it is then determined whether the 404 graphics processing unit (e.g., GPU 312) has been correctly configured according to the configuration data. This step may involve determining whether the configuration data has been correctly written into one or more registers in register bank 350. For example, it may be determined whether the register entries specified in the configuration data have been written into register bank 350 with the specified configuration.

[0069] In one example, security controller 311 can compare configuration data with the results of configuration steps. The comparison can be performed in any appropriate manner.

[0070] In one example, security controller 311 can read back the contents (e.g., a set of data entries) of each register in register bank 350 and compare their contents with expected contents based on the configuration data. That is, for each register, security controller 311 can check whether the read register entry matches the expected register entry for that register. In one example, the comparison can be performed before the register entries are subsequently modified as a result of rendering performed by the GPU. That is, before processing unit 339 accesses the contents of the registers to perform rendering. In another example, a snapshot of the register bank can be stored in host data processing system 302. The snapshot can be a process of reading data entries from the registers of register bank 350 back to memory outside the GPU (e.g., memory 307 in host data processing system 302). The snapshot of register bank 350 can be published and sent 334, 337 to security controller 331 (e.g., via memory 307) for comparison with configuration data. In this example, the snapshot of register bank 350 can be verified by comparing it with expected contents based on the configuration data. That is, for each register, the security controller 311 can check whether the register entry found in the snapshot matches the expected register entry for that register. While performing this comparison, the actual register contents can be used for rendering.

[0071] In another example, security controller 311 can perform a comparison by performing a check on the contents of a register (e.g., a set of data entries) and comparing it to an equivalent checksum performed on configuration data. The checksum can depend on the location of the data within the register. In other words, the checksum can not be location-invariant. That is, the checksum calculation can take into account the values ​​of the stored register entries and their locations within register bank 350. In other words, the checksum can return different results when (i) the expected register entry is stored in the correct register location and (ii) the expected register entry is stored in the incorrect register location. In one example, security controller 311 can read back the contents of each register in register bank 350 to perform the checksum. In another example, a snapshot of register bank 350 can be stored by external memory (such as memory 307 in host data processing system 302) to perform the checksum.

[0072] In one example, firmware 314 can compare configuration data with the results of configuration steps. The comparison can be performed in any appropriate manner.

[0073] In one example, firmware 314 can read back the contents (e.g., a set of data entries) of each register in register bank 350 and compare their contents with expected contents according to the configuration data. That is, for each register, the firmware can check whether the read register entry matches the expected register entry for that register. In one example, the comparison can be performed before the register entries are subsequently modified as a result of rendering performed by the GPU. That is, before processing unit 339 accesses the contents of the registers to perform rendering. In another example, a snapshot of the register bank can be stored by firmware 314. The snapshot can be reading data entries from the registers of register bank 350 back into internal core memory (not shown) dedicated to firmware 314. In this example, the snapshot of register bank 350 can be verified by comparing it with expected contents according to the configuration data. That is, for each register, the firmware can check whether the register entry found in the snapshot matches the expected register entry for that register. While the comparison is being performed, the actual register contents can be used for rendering.

[0074] In another example, firmware 314 can perform a comparison by performing a checksum on the contents of a register (e.g., a set of data entries) and comparing it to an equivalent checksum performed on configuration data. The checksum can depend on the location of the data within the register. In other words, the checksum can not be location-invariant. That is, the checksum calculation can take into account the values ​​of the stored register entries and their locations within register bank 350. In other words, the checksum can return different results when (i) the expected register entry is stored in the correct register location and (ii) the expected register entry is stored in the incorrect register location. In one example, firmware 314 can read back the contents of each register in register bank 350 to perform the checksum. In another example, a snapshot of register bank 350 can be stored by firmware 314 to perform the checksum.

[0075] In some examples, the GPU firmware (e.g., firmware 314) sets flags or status values ​​to confirm that the determination step has been completed. Different flags or status values ​​can be used to indicate whether it has been determined that the GPU 312 has been configured correctly or incorrectly.

[0076] In some examples, any combination of two or more of the comparisons described herein may be performed to determine whether the graphics processing unit (e.g., GPU 312) has been correctly configured according to the configuration data.

[0077] Based on the principles described herein, if it is determined that the graphics processing unit has not been correctly configured according to the configuration data, then a 405 initialization error has occurred.

[0078] In response to determining that an initialization error has occurred, the safety controller can reset the graphics processing unit. For example, refer to... Figure 3 If firmware 314 determines that GPU 312 is not configured according to the configuration data, it can notify the host data processing system of an initialization error 334 by returning to buffer 310 in memory 307. Security controller 311 can then cause GPU 312 to reset via command 336 reset unit 351.

[0079] Hardware recovery reset is an example of such a reset. A reset may include returning some or all of the GPU triggers to a known safe state, and / or invalidating some or all of the data stored in memory such as register bank 350 within the GPU 312. A reset can eliminate certain errors, such as those that cause GPU failure (e.g., errors that cause the GPU to be incorrectly configured). Resetting the GPU in this way allows errors in configuration to be corrected before they cause errors in the graphics rendering of frames or tiles.

[0080] A reset can include any other type of reset. For example, a reset can be a soft reset. A soft reset can include resetting the hardware components of GPU 312. For example, during a soft reset, processing unit 339 can be reinitialized and returned to a known state, and register entries in register bank 350 can be invalidated. During a soft reset, software components of GPU 312, such as firmware 314, can continue to operate. Conversely, a reset can be a hard reset. A hard reset can include resetting both the hardware and software components of GPU 312. For example, during a hard reset, processing unit 339 and firmware 314 can be reinitialized and returned to a known state, and register entries in register bank 350 can be invalidated or cleared. Any other type of reset, including any other combination of invalidating register entries in register bank 350 and resetting components of the graphics processing unit (e.g., GPU 312), is also possible.

[0081] In other examples, the security controller 311 can notify other entities outside the GPU 312 that an initialization error has occurred. For example, the security controller can forward a detected initialization error to an application 301 running on the host data processing system 302, such as an application that submitted a rendering call associated with the initialization error.

[0082] The graphics processing unit can be referenced Figure 4Rendering is performed before the security check described is completed. If the security check determines that the graphics processing unit has been configured according to the configuration data, rendering of the graphics data can continue. For example, rendering of graphics data that has already started can continue unaffected, or rendering of graphics data can not begin until the security check has been completed.

[0083] refer to Figure 5 Describes another type of security check initiated by security controller 311.

[0084] Figure 5 This is a flowchart 500 of another method for initializing safety-critical rendering at the graphics processing unit within a graphics processing system, based on the principles described herein.

[0085] Instructions for initializing the rendering of safety-critical graphics data at the graphics processing unit (GPU 312) are written into the 501 graphics processing unit. As previously described, a safety check can be performed when the GPU 312 is initialized to perform the rendering of a graphics data frame. The frame or tile may include data for safety-critical rendering. A safety check can be performed whenever the GPU 312 is initialized to perform the rendering of a safety-critical data frame, or on a subset of these occasions. In another example, a safety check can be performed when the GPU 312 is initialized to perform the rendering of a tile of graphics data. The tile may include data for safety-critical rendering. A safety check can be performed each time the GPU 312 is initialized to perform the rendering of a tile of safety-critical data, or on a subset of these occasions. A safety check can be performed when initializing geometry processing, fragment processing, or both geometry processing and fragment processing.

[0086] Instructions used to initiate the rendering of safety-critical graphics data include requests for responses from the GPU. Requests for responses may instruct the GPU to respond immediately after reading the request or after completing a predetermined task. Requests for responses may be embedded as flags within the instructions. For example, the flags may exist in the instruction header. The instruction header may be in the instruction's initiation command. The initiation command is the name given to the instruction or a portion of the instruction that instructs the GPU to begin processing rendering or a portion of rendering.

[0087] Timer 502 can be initialized. Return. Figure 3 The diagram schematically illustrates timer 352 as a component of safety controller 311. This is because timer 352 can be controlled by safety controller 311. It should be understood that the timer can be located remotely from safety controller 311. The timer can be configured to expire after a certain period of time.

[0088] The time period can be defined as a real-time metric. For example, the time period could be 1 ms. Alternatively, the time period can be defined relative to a number of processor clocks (e.g., based on the clock rate of the GPU on which processing is being initialized). For example, the time period could be 1,000,000 clock cycles.

[0089] The time period can be set relative to the expected duration of the graphics processing being initialized. For example, the time period can be set such that it represents a fraction or percentage of the expected duration of the graphics processing being initialized. For example, the time period can be set to 10% of the expected duration of the graphics processing being initialized. That is, the time period can be determined based on the graphics processing being initialized.

[0090] In other examples, the timer period can be predetermined. For example, the time period can be set at design time. The time period can be set at design time for the graphics processing system or for the individual graphics processing units included in the graphics processing system. Alternatively, the time period can be user-configurable. The user can set the desired time period when configuring the application 301 running on the host data processing system 302. In another example, the desired time period can be determined by the application 301 running on the host data processing system 302. The application can communicate the desired time period to the security controller 311 (e.g., in...). Figure 3 In the example shown, via API 303 in driver 304.

[0091] In the example, the timer can be initialized when an instruction for initializing the rendering of safety-critical graphics data at the GPU is sent from the security controller 311 (e.g., to buffer 308 in memory 307) as instruction 332. In another example, the timer can be initialized when instruction 333 is sent from the host data processing system 302 (e.g., when the instruction leaves buffer 308). The timer can be initialized at any other suitable time.

[0092] During the stated time period, the security controller monitors 503 responses from the graphics processing unit (e.g., GPU 312). As described herein, instructions for initiating the rendering of security-critical graphics data include requests for responses from the GPU. References Figure 3 The firmware 314 of GPU 312 can act on request responses. For example, upon receiving (e.g., via 333) an instruction from GPU 312 including a request for a response, firmware 314 can read the request for a response and then send a 334 response to security controller 311 (e.g., via memory 307). Any suitable response can be sent. For example, the response may include an interrupt. The interrupt may cause host data processing system 302 to read messages from system memory.

[0093] Based on the principles described in this article, if no response is received from the GPU before the timer expires, a 504 initialization error is determined to have occurred.

[0094] Upon determining that an initialization error has occurred, the safety controller can reset the graphics processing unit. (See reference) Figure 3 The security controller 311 can cause the GPU 312 to reset via command 336 to reset unit 351. As described herein, the reset performed can be a hardware recovery reset, a soft reset, a hard reset, or any combination thereof that may involve resetting one or more units of the GPU 312.

[0095] In other examples, the security controller 311 can notify other entities outside the GPU 312 that an initialization error has occurred. For example, the security controller can forward a detected initialization error to an application 301 running on the host data processing system 302, such as an application that submitted a rendering call associated with the initialization error.

[0096] In some examples, no response is received from the GPU because the GPU has stopped, locked, or failed. For example, a failure may occur when an invalid memory access happens and the memory management unit signals a page fault. Therefore, the implementation of the references in this document... Figure 5 The described method enables GPU stoppages or lockouts to be effectively identified and resolved (e.g., by resetting).

[0097] It can be executed on the graphics processing unit as per the reference. Figure 5 The described security check is performed concurrently with the rendering of graphics data by the graphics processing unit. If a response is received before the said time period expires, the rendering of graphics data can continue. For example, rendering of graphics data that has already begun can continue unaffected, or the rendering of graphics data can continue until the security check has been completed.

[0098] Combined use reference Figure 4 and 5 The method described. (See reference) Figure 6 This describes the type of security check initiated by security controller 311.

[0099] Figure 6 This is a flowchart 600 of another method for initializing safety-critical rendering at the graphics processing unit within a graphics processing system, based on the principles described herein.

[0100] Configuration data 601 can be generated to initialize the rendering of safety-critical graphics data at a graphics processing unit (e.g., GPU 312). References can be found here. Figure 4The principles described are used to generate configuration data.

[0101] Configuration data and instructions, including requests for responses from graphics processing units (as described herein), can be written into a 602 graphics processing unit (e.g., GPU 312). References herein may be made to this document. Figure 4 The described principle involves writing configuration data into the GPU. In one example, the configuration data can be included within a launch command that includes a request for a response from the GPU. For instance, the configuration data could form the body of the command, while the request for a response from the GPU exists as an instruction flag in the command header. In another example, the configuration data can be included within one or more different instructions.

[0102] Timer 603 can be initialized. The timer can be configured to expire after a specified period. See here for reference. Figure 5 The principle described herein is used to initialize the timer. During the time period, the safety controller operates according to the principles outlined in this document. Figure 5 The principle described is to monitor the response from the graphics processing unit (e.g., GPU 312).

[0103] This article can be used as a reference Figure 4 The described principle involves configuring a 604 graphics processing unit (e.g., GPU 312) based on configuration data in the instructions. As described herein, the instructions include requests for responses from the GPU. In one example, once GPU 312 has been configured according to the configuration data, a request is made to send a response from the GPU. In another example, once firmware 314 has read the request for a response, it requests to send a response from GPU 312.

[0104] According to the references in this article Figure 4 The described principle determines whether the 605 graphics processing unit (e.g., GPU 312) has been correctly configured according to the configuration data.

[0105] Based on the principles described herein, if it is determined that the graphics processing unit has not been correctly configured according to the configuration data, then a 606 initialization error is determined to have occurred. Furthermore, based on the principles described herein, if it is determined that no response has been received from the GPU before the timer expires, then a 606 initialization error is determined to have occurred.

[0106] In response to determining that an initialization error has occurred, the safety controller can reset the graphics processing unit, as shown in the reference. Figure 4 and Figure 5As described. In other examples, the security controller 311 can notify other entities outside the GPU 312 that an initialization error has occurred. For example, the security controller can forward a detected initialization error to an application 301 running on the host data processing system 302, such as an application that submitted a rendering call associated with the initialization error.

[0107] It can be executed on the graphics processing unit as per the reference. Figure 6 The described security check is performed concurrently with the rendering of graphics data by the graphics processing unit. If it is determined that the graphics processing unit has been configured according to the configuration data and a response is received before the expiration of the time period, the rendering of the graphics data can continue. For example, rendering of graphics data that has already begun can continue unaffected, or the rendering of graphics data can be delayed or paused until the security check has been completed.

[0108] In the example, a second timer can be initialized. The second timer can be configured to expire after a second time period. The second time period can be shorter than the time period described earlier in this document (referred to as the first time period in the following paragraphs, and associated with the first timer).

[0109] Each time period can be defined as a real-time metric. For example, the first time period could be 1 ms, and the second time period could be 0.5 ms. Alternatively, each time period can be defined relative to a number of processor clocks (e.g., based on the clock rate of the GPU on which processing is being initialized). For example, the first time period could be 1,000,000 clocks, and the second time period could be 500,000 clocks.

[0110] Each time period can be set relative to the expected duration of the graphics processing being initialized. For example, each time period can be set such that it represents a fraction or percentage of the expected duration of the graphics processing being initialized. For instance, a first time period could be set to 10% of the expected duration of the graphics processing being initialized, and a second time period could be set to 5% of the expected duration of the graphics processing being initialized. In other words, each time period can be determined based on the graphics processing being initialized.

[0111] In other examples, each timer period can be predetermined. For example, each time period can be set at design time. Each time period can be set at design time for the graphics processing system or for the individual graphics processing units included in the graphics processing system. Alternatively, each time period can be user-configurable. The user can set the desired time period when configuring the application 301 running on the host data processing system 302. In another example, the desired time period can be determined by the application 301 running on the host data processing system 302. The application can communicate the desired time period to a security controller (e.g., in...). Figure 3 In the example shown, via API 303 in driver 304.

[0112] The first and second timers can be initialized simultaneously.

[0113] During the first and second time periods, the security controller can monitor responses from the graphics processing unit (e.g., GPU 312). For example, once it has been determined whether the GPU has been configured according to the configuration data, the GPU 312 can be instructed to respond, as per reference... Figure 6 As described.

[0114] In one example, if no response is received before the second time period expires, but a response is received before the first time period expires, and it is determined that the GPU has been correctly configured according to the configuration data, then it can be determined that GPU 312 is operating correctly (e.g., the GPU has not been locked, stopped, or malfunctioned), but its workload has exceeded an acceptable threshold. In this example, the security controller can manage the workload of GPU 312. For example, the security manager can cause the rate at which graphics processing instructions are sent to the GPU to be reduced. The extent to which the GPU's workload is reduced may depend on the duration exceeded before a response is received.

[0115] For reference here Figure 6 Describe the safety controller's response to monitoring performed during the first time period.

[0116] According to the references in this article Figure 4 , 5 The principle described in section 6, which initializes rendering, is superior to performing a reset only in response to a detected fault in the GPU's rendering output (e.g., a frame or tile rendered by the graphics processing unit). This is because the latter approach typically involves waiting for the frame to finish rendering before an error can be detected. In some examples, an improperly configured GPU may not even be able to complete the reproduction of a frame or tile. (Refer to this reference.) Figure 4 , 5The security checks performed according to the principle described in Or 6 can be performed in a fraction of the time typically spent rendering a frame. Therefore, faults can be detected before they manifest in incorrectly rendered frames or tiles (and before the GPU commits time and resources to rendering those frames or tiles incorrectly), and optionally cleared by resetting the GPU. Thus, fault detection and elimination can be performed more efficiently.

[0117] For example, detecting transient faults may require implementing a double-locked-step arrangement, as shown in the reference. Figure 1 As described herein, in such an arrangement, a pair of identical processing cores 101 and 102 are configured to process instruction stream 103 in parallel. The outputs of processing cores 101 and 102 can be compared. When the outputs of processing cores 101 and 102 do not match, a fault can be triggered to a safety-critical system. This fault detection method requires rendering of frames or tiles so that the outputs of each of processing cores 101 and 102 can be compared. Furthermore, a second processing core is required to implement the dual-locked-step processor, making them expensive because they necessarily consume twice the chip area and approximately twice the power compared to conventional processors. That is to say, it should be understood that the method of initializing safety-critical rendering at the graphics processing unit according to the principles described herein can be used in conjunction with such a method. This may be suitable for graphics processing systems with stringent safety requirements. For example, rendering can be initialized for one or both of processing cores 101 and 102 in a dual-locked-step arrangement according to the principles described herein.

[0118] Initializing rendering according to the principles described in this article also improves the robustness of the graphics processing system by verifying the data path from the host data processing system through its firmware to the GPU's register library.

[0119] The security controller 311 can selectively perform security checks only on the GPU performing security-critical rendering. For example, Figure 2The illustrated instrument cluster 200 includes a speedometer 202 in a conventional dial format, with speed values ​​208 around the edge of the dial and a pointer 207 whose angular direction indicates the vehicle's current speed. The instrument cluster 200 also includes an oil temperature gauge 203, an information icon 204 (e.g., indicating the selected radio station), a non-critical warning icon 205 (e.g., indicating a malfunction in the air conditioning system), and a critical warning icon 206 (e.g., indicating a serious engine problem). In this example, only the speedometer 202 and the critical warning icon 206 are considered critical to the safety of the vehicle and its occupants. It may be necessary to render these display elements in a manner that meets mandatory safety levels (e.g., ASIL B of the ISO 26262 standard). The oil temperature gauge 203, information icon 204, and non-critical warning icon 205 do not need to be rendered according to this safety level. The rendering space used to render the frame representing the rendered instrument cluster is divided into multiple tiles 201, each tile comprising multiple pixels. Only the highlighted tiles 209 contain critical display elements because at least a portion of the critical display elements overlaps with each highlighted tile. The security controller 311 can perform security checks only on one or more processing units 339 or GPUs configured to perform rendering of highlighted tiles, and / or only on instructions associated with rendering of highlighted tiles.

[0120] Figure 3 The graphics processing system is shown as comprising multiple functional blocks. This is merely illustrative and not intended to define a strict division between different logical elements of such an entity. Each functional block may be provided in any suitable manner. It should be understood that the intermediate values ​​described herein formed by the graphics processing system do not need to be physically generated by the graphics processing system at any point in time, and may merely represent logical values ​​that conveniently describe the processing performed by the graphics processing system between its inputs and outputs.

[0121] The graphics processing system described herein can be embodied in hardware on one or more integrated circuits. The graphics processing system described herein can be configured to perform any of the methods described herein.

[0122] As used herein, the terms computer program code and computer-readable instructions refer to any kind of executable code for a processor, comprising code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, bytecode, code defining integrated circuits (e.g., hardware description languages ​​or netlists), and code expressed in programming languages ​​such as C, Java, or OpenCL. Executable code can be, for example, any kind of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, or run in a virtual machine or other software environment, causes the processor of a computer system that supports the executable code to perform tasks specified by said code. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disks, flash memory, hard disks, and other memory devices that can use magnetic, optical, and other techniques to store instructions or other data and are accessible by a machine.

[0123] A processor, computer, or computer system can be any kind of device, machine, or special-purpose circuit, or a collection or part thereof, that has the processing power to execute instructions. A processor can be any kind of general-purpose or special-purpose processor, such as 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.

[0124] This invention also intends to cover software, such as hardware description language (HDL) software, that defines the configuration of hardware as described herein for designing integrated circuits or configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided on which computer-readable program code in the form of an integrated circuit definition dataset is encoded, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a graphics processing system configured to perform any of the methods described herein, or to manufacture a graphics processing system including any of the devices described herein. The integrated circuit definition dataset may, for example, be an integrated circuit description.

[0125] A method for manufacturing a graphics processing system as described herein can be provided in an integrated circuit manufacturing system. An integrated circuit definition dataset can be provided, which, when processed in the integrated circuit manufacturing system, causes the method for manufacturing the graphics processing system to be executed.

[0126] Integrated circuit definition datasets can be in the form of computer code, such as as a netlist, code for configuring programmable chips, or a hardware description language for defining integrated circuits at any level, including register-transfer level (RTL) code, high-level circuit representations such as Verilog or VHDL, and low-level circuit representations such as OASIS (RTM) and GDSII. Higher-level representations that logically define integrated circuits (e.g., RTL) can be processed at a computer system configured to generate manufacturing definitions of integrated circuits within a software environment that includes definitions of circuit elements and rules for combining those elements to generate manufacturing definitions of integrated circuits defined by said representation. As is typically the case where software executes at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate manufacturing definitions of integrated circuits, executing code that defines the integrated circuits to generate those manufacturing definitions.

[0127] Now refer to Figure 7 This describes an example of processing integrated circuit definition datasets at an integrated circuit manufacturing system in order to configure the system for manufacturing graphics processing systems.

[0128] Figure 7 An example of an integrated circuit (IC) manufacturing system 702 is shown, configured to manufacture a graphics processing system as described in any of the examples herein. Specifically, the IC manufacturing system 702 includes a layout processing system 704 and an integrated circuit generation system 706. The IC manufacturing system 702 is configured to receive an IC definition dataset (e.g., defining a graphics processing system as described in any of the examples herein), process the IC definition dataset, and generate an IC (e.g., embodying the graphics processing system as described in any of the examples herein) based on the IC definition dataset. Through the processing of the IC definition dataset, the IC manufacturing system 702 is configured to manufacture an integrated circuit embodying the graphics processing system as described in any of the examples herein.

[0129] The layout processing system 704 is configured to receive and process an IC definition dataset to determine a circuit layout. Methods for determining a circuit layout based on an IC definition dataset are known in the art and may involve, for example, synthesizing RTL code to determine a gate-level representation of the circuit to be generated, for example, in relation to logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining the location information of the logic components, the circuit layout can be determined based on the gate-level representation of the circuit. This can be done automatically or with user intervention to optimize the circuit layout. Once the layout processing system 704 has determined the circuit layout, it can output the circuit layout definition to the IC generation system 706. The circuit layout definition may be, for example, a circuit layout description.

[0130] As is known in the art, IC generation system 706 generates ICs according to a circuit layout definition. For example, IC generation system 706 may implement a semiconductor device manufacturing process for generating ICs, which may involve a multi-step sequence of photolithography and chemical processing steps, during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask, which can be used in the photolithography process to generate ICs according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 706 may be in the form of computer-readable code, which IC generation system 706 can use to form a suitable mask for generating ICs.

[0131] The various processes performed by the IC manufacturing system 702 can all be implemented in one location, for example, by one party. Alternatively, the IC manufacturing system 702 can be a distributed system, allowing some processes to be performed in different locations and by different parties. For example, some of the following stages can be performed in different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition dataset to form a gate-level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0132] In other examples, processing of an integrated circuit definition dataset in an integrated circuit manufacturing system can configure the system to manufacture a graphics processing system without processing the IC definition dataset to determine circuit layout. For example, an integrated circuit definition dataset can define the configuration of a reconfigurable processor, such as an FPGA, and processing of the dataset can configure the IC manufacturing system (e.g., by loading the configuration data into the FPGA) to generate a reconfigurable processor with the defined configuration.

[0133] In some implementations, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition dataset can enable the integrated circuit manufacturing system to generate devices as described herein. For example, the integrated circuit manufacturing definition dataset referenced above... Figure 7 The described method allows for the configuration of integrated circuit manufacturing systems to produce devices as described in this article.

[0134] In some examples, an integrated circuit definition dataset may include software running on hardware defined at the dataset, or software running in combination with hardware defined at the dataset. Figure 7 In the example shown, the IC production system can be further configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to program code defined at the integrated circuit definition dataset during the manufacturing of the integrated circuit, or otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0135] Compared to known implementations, the implementation of the concepts set forth in this application in devices, apparatuses, modules, and / or systems (and in the methods implemented herein) can lead to performance improvements. Performance improvements may include one or more of increased computational performance, reduced latency, increased throughput, and / or reduced power consumption. During the manufacture of such devices, apparatuses, modules, and systems (e.g., in integrated circuits), trade-offs can be made between performance improvements and physical implementation methods, thereby improving manufacturing methods. For example, a trade-off can be made between performance improvements and layout area to match the performance of known implementations but using less silicon. This can be accomplished, for example, by reusing functional blocks serially or sharing functional blocks among elements of a device, apparatus, module, and / or system. Conversely, the concepts set forth in this application that lead to improvements in the physical implementation of devices, apparatuses, modules, and systems (such as reduced silicon area) can be traded off for performance improvements. This can be accomplished, for example, by manufacturing multiple instances of a module within a predefined area budget.

[0136] The applicant has independently disclosed each individual feature described herein, as well as any combination of two or more such features, to the extent that such features or combinations can be implemented based on the specification as a whole, in accordance with the common knowledge of those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein. In view of the foregoing description, those skilled in the art will understand that various modifications can be made within the scope of this invention.

Claims

1. A method for initializing rendering at a graphics processing unit, the graphics processing unit being configured to perform safety-critical rendering within a graphics processing system, the method comprising: Generate configuration data for initializing the rendering of safety-critical graphics data at the graphics processing unit, wherein the configuration data specifies the configuration to be adopted by the graphics processing unit; The configuration data for initializing rendering is received at the graphics processing unit; The graphics processing unit is configured according to the configuration data by writing the configuration data used to initialize rendering into one or more registers of the graphics processing unit; Whether the graphics processing unit is correctly configured according to the configuration data is determined by determining whether the configuration data is correctly written into one or more registers of the graphics processing unit; and In response to determining that the graphics processing unit is not correctly configured according to the configuration data, an initialization error is determined by a security controller external to the graphics processing unit.

2. The method of claim 1, wherein the security controller resets the graphics processing unit in response to determining that the initialization error has occurred.

3. The method according to claim 1 or 2, wherein the method further comprises: In response to determining that the graphics processing unit is correctly configured according to the configuration data, the rendering of safety-critical graphics data continues at the graphics processing unit.

4. The method of claim 1 or 2, wherein the configuration data includes one or more register entries to be written to one or more registers of the graphics processing unit.

5. The method according to claim 1 or 2, wherein the generation of configuration data is performed by the security controller.

6. The method of claim 4, wherein configuring the graphics processing unit according to the configuration data comprises one of the following: The security controller writes the one or more register entries into one or more registers of the graphics processing unit; or The firmware of the graphics processing unit writes the one or more register entries into one or more registers of the graphics processing unit.

7. The method of claim 4, wherein determining whether the graphics processing unit has been correctly configured according to the configuration data comprises: After configuring the graphics processing unit, read back the one or more register entries corresponding to the configuration data from each of the one or more registers of the graphics processing unit; and One or more register entries read back from each register are compared with the expected data entries for the registers specified by the configuration data.

8. The method of claim 4, wherein determining whether the graphics processing unit has been correctly configured according to the configuration data comprises: After configuring the graphics processing unit, a snapshot of the one or more register entries corresponding to the configuration data is stored in one or more registers of the graphics processing unit; as well as The one or more register entries of each register in the snapshot are compared with the expected data entries of the register specified by the configuration data.

9. The method of claim 4, wherein determining whether the graphics processing unit has been correctly configured according to the configuration data comprises: After configuring the graphics processing unit, read back the one or more register entries corresponding to the configuration data from each of the one or more registers of the graphics processing unit; Perform a checksum on the one or more register entries read back from the one or more registers; Perform checks and additions on the configuration data; as well as Compare the results of the above checks.

10. The method of claim 4, wherein determining whether the graphics processing unit has been correctly configured according to the configuration data comprises: After configuring the graphics processing unit, a snapshot of the one or more register entries corresponding to the configuration data is stored in one or more registers of the graphics processing unit; Perform a checksum on the one or more register entries in the snapshot; Perform checks and additions on the configuration data; as well as Compare the results of the above checks.

11. The method of claim 9, wherein the checking depends on the position of the one or more register entries within one or more registers of the graphics processing unit.

12. The method according to claim 1 or 2, wherein the method comprises: Instructions for initiating the rendering of safety-critical graphics data at the graphics processing unit are written into the graphics processing unit, the instructions including requests for responses from the graphics processing unit. Initialize the first timer, which is configured to expire after a first time period; as well as The response from the graphics processing unit is monitored during the first time period; as well as If no response is received from the graphics processing unit before the first timer expires, the security controller determines that an initialization error has occurred.

13. The method of claim 12, wherein the time period is determined based on the safety-critical graphical data to be rendered.

14. The method according to claim 12, further comprising: Initialize a second timer, which is configured to expire after a second time period, which is shorter than the first time period; as well as During the second time period, the response from the graphics processing unit is monitored; The security controller is configured to reduce the workload of the graphics processing unit if the following conditions are met: No response was received from the graphics processing unit before the second timer expired; Receive a response from the graphics processing unit before the first timer expires; and It is determined that the graphics processing unit has been correctly configured according to the configuration data.

15. A graphics processing system, comprising: A graphics processing unit for performing safety-critical rendering, the graphics processing unit being configurable according to configuration data used to initialize the rendering; Host data processing system, wherein the host data processing system is configured as follows: Generate configuration data for initializing safety-critical graphics data rendering at the graphics processing unit, wherein the configuration data specifies the configuration to be adopted by the graphics processing unit; and The graphics processing unit is configured according to the configuration data by writing the configuration data for initializing rendering into one or more registers of the graphics processing unit; as well as A security controller located outside the graphics processing unit is configured as follows: Whether the graphics processing unit is correctly configured according to the configuration data is determined by determining whether the configuration data is correctly written into one or more registers of the graphics processing unit; and In response to determining that the graphics processing unit is not correctly configured according to the configuration data, it is determined that an initialization error has occurred.

16. The graphics processing system of claim 15, wherein the security controller resets the graphics processing unit in response to determining that the initialization error has occurred.

17. The graphics processing system according to claim 15 or 16, wherein the graphics processing unit is configured to: In response to the safety controller determining that the graphics processing unit is correctly configured according to the configuration data, the rendering of safety-critical graphics data continues.

18. A non-transitory computer-readable storage medium storing computer-readable instructions thereon, the computer-readable instructions, when executed at a computer system, causing the computer system to perform a method for initializing rendering at a graphics processing unit, the graphics processing unit being configured to perform safety-critical rendering within a graphics processing system, the method comprising: Generate configuration data for initializing the rendering of safety-critical graphics data at the graphics processing unit, wherein the configuration data specifies the configuration to be adopted by the graphics processing unit; The configuration data for initializing rendering is received at the graphics processing unit; The graphics processing unit is configured according to the configuration data by writing the configuration data used to initialize rendering into one or more registers of the graphics processing unit; Whether the graphics processing unit is correctly configured according to the configuration data is determined by determining whether the configuration data is correctly written into one or more registers of the graphics processing unit; and In response to determining that the graphics processing unit is not correctly configured according to the configuration data, an initialization error is determined by a security controller external to the graphics processing unit.

Images