_{Asked by Alexander Schulz from Renesas}

Wherever parallel processing is implemented via many instances of the same circuit design, any random faults in said circuits can be detected by pairing up identical circuit instances and then running a test vector on both and comparing the output via a simple and robust comparator checker circuit, IMG term a pair of such circuit instances a ‘Safety-Pair’. This approach uses the parallelised logic already available in the GPU, whereby the comparator overhead is negligible. An example of a safety pairs is where every ALU in a GPU thread-block is paired with an identical ALU in the same block. A feature of parallel arithmetic processing arrays within the GPU is that due to their nature, and the nature of the compute and graphics workloads that use them, is that they are rarely fully utilised over a given time window. This provides the GPU the ability to detect the idle cycles on which a Safety-Pair is not being used by the overarching workload, which can then be ‘stolen’, or borrowed, and utilised instead to execute test vectors which can detect faults in either circuit within the Safety-Pair. IMG term this approach as ‘Idle Cycle Stealing’ (ICS). A related property of this Safety-Pair approach is that the processing logic within Safety-Pairs with idle cycle fault detection can be configured to only execute fault-finding tests when that logic is being or has recently been actively used by a safety-related workload.

In order to guarantee the detection of faults within a Safety-Pair, it is necessary to run multiple test vectors and to derive the vectors that get the best coverage using a principled and measurable technique based on fault-injection campaigns of the safety pair circuits. IMG have conducted this work and have provided a default suite of test vectors within the GPU in order to support the achievement of diagnostic coverage for the integrity required while sustaining performance. However, these test vectors are also system integrator-configurable and may be further tuned depending on end-user requirements, diagnostic targets and use-cases. In the event that there may be insufficient idle cycles available, an additional mechanism is introduced in order to ‘force’ idle cycles in the pipeline as required to complete all test vectors within the FHTI window, the area and power overhead for this logic is again negligible, as is the performance impact.

_{Asked by Ali Topcu from Valeo}

That’s a great question—and it speaks directly to one of the key advantages of our GPU architecture. Virtualization is a core capability of our IP, and it’s particularly important in the automotive space. Why? Because it enables OEMs and Tier 1s to reduce the production bill of materials by consolidating multiple applications—whether safety-critical or not—onto a single hardware platform. Our GPU includes hardware-based virtualization built directly into the architecture. This allows for logical and temporal isolation between applications, ensuring safety-critical and non-safety-critical tasks can run concurrently on the same GPU without interference. This is supported by internal memory management and protection units, and the GPU can run under a hypervisor to further ensure robust separation. Importantly, this virtualization capability is designed and verified in line with ISO 26262 processes. We’ve also taken into account elements outside our direct control at the IP level, such as external memory, clocks, and power. Provisions for these are made at the SoC level to maintain safety integrity.What’s more, our experience in consumer graphics means we’ve been implementing and refining virtualization for years. This depth of expertise translates directly to the automotive-grade IP we offer today.With our multi-core GPU products, the benefits grow even further. You can dedicate different cores to different applications, enhancing isolation and delivering a real boost in performance. In short, our GPU architecture offers a powerful, flexible, and cost-efficient platform for modern automotive workloads.

_{Asked by Andrew MacDonald from Mira}

All the safety mechanisms are abstracted from the application level – that’s the beauty of this approach, instrinsically safe hardware makes for a simpler/easier and usually more cost effective approach to system development, whereby most of the cost/complexity arguably lies in the software stack. What’s needed here is the appropriate Firmward and Driver (what we call our Device Development Kit or DDK), whereby a functional and conformative DDK is available directly from IMG (i.e. one that enables the safety mechanisms to be utilised, and supports customer system integration and testing), and, and ISO 26262 compliant DDK will be available in the near future aligned to our software roadmap.

_{Asked by Daniel Ezekiel from Semi Conductor Consulting}

All modern pipelined procuessing units, whether CPU or GPU based, are highly unlikley to be 100% utilised in any given time window – this is largely down to the inherently underterministic nature of these devices, whereby various features have improved hardware/pipline utilisation over time. One compund reason for this is memory latency as you have identified, which is impossible for an IP company to manage, although we do conduct various latency analysis modelling to ensure predicatble and stable GPU IP behaviour. In any case, these idle cycles within the pipelines, while not ideal for performance, create opportunities to run safety-related checks. Though full GPU utilization is an overarching goal, it’s not always achievable due to how workloads are allocated from the Host system/CPUs and the variable nature of processing demands, especially in a mixed criticilay system configuration / Virtualisation scenario. In an automotive landscape, arguable the quality of the SW within the system should be better than any given consumer orientated device. Furthermore, by using our PowerVR tools and the DDK to develop, manage and optimize workload processing, any development team can utilise our built in safety contorl mechanisms without any significant performance trade-offs. Ultimately, the architecture’s high parallelism and flexibility, while complex, become assets in embedding functional safety without compromising overall system throughput.

_{Asked by Daniel Ezekiel from Semi Conductor Consulting}

Imagination’s GPU stands out thanks to its distributed hardware safety architecture, which enables real-time fault detection directly in processing logic with minimal silicon and performance overhead. Unlike software-only methods that offer limited diagnostics capability and cannot mitage against soft errors, our hardware-based approach detects faults earlier and more reliably. This distributed solution is: More efficient – avoids replicated workloads while ensuring safety.; More robust – handles soft errors / transient faults that software libraries miss; Customer-friendly – reduces complexity in ovreall system integration, validation, including software development; leading to a more balanced solution – one that can deliver high diagnostic coverage without significantly compromising performance or area. In short, our GPU offers intrinsically safer hardware that simplifies safety design and verification for our customers, especially in cost- and safety-critical automotive applications.

_{Asked by Dave Johnson from Synopsys}

The DXS GPU is designed with flexibility in mind, making it suitable for a wide range of automotive applications—from infotainment and HMI to safety-critical functions. Its flexibility also introduces safety challenges, which the engineering team addressed through detailed hazard analysis, failure mode evaluation, derivation of safety requirements and the development of targeted safety mechanisms. This result provides good diagnostic coverage for both processing logic and memories, which meets ASIL-B expectations as set out by the ISO 26262 standard. By collaborating closely with automotive customers, Imagination Technologies has refined its understanding of real-world use-cases, ensuring any assumptions we declare are transparent, well-documented, reasonable and credible. Safety requirements are ultimately derived from these use-case scenarios and decomposed into actionable technical safety requirements. All of our assumptions and desciptions of the safety archeicture are delivered as part of a complete safety package (includisive of a Hardware Safety Manual, a Safety Anlaysis Summary report, FMEDA, and a Safety Case report, along with a copy/link to the product certification from a 3rd party assessor), supporting innovation while demonstrably maintaining compliance with the automotive functional safety standard.

_{Asked by Dave Johnson from Synopsys}

At Imagination, we leverage deep in-house expertise to help customers manage hardware safety challenges such as common mode failures, EMC interference, self-heating, and radiation etc., supported by a detailed CCF/CMF/Dependant Failure Anlaysis. While we do not (cannot) implement system-level safety measures ourselve s— as an IP provider — we instead offer guidance and preliminary advice through customer facing resources like our hardware safety manual. This support helps customers at the SoC or system level address failure initiators and design resilient solutions for thier application.

_{Asked by Romain Poyet from Bosch}

Availability (and reliability) is a system attribute which is subtly different to safety. ISO 26262 stricktly does not define any availability requirements, although one could be inferred from the general reliability target assocatied with, for example, ASIL-B. Fundamentally, as a saftey element out of context develpoment (SEooC), our IP merely attempts to reduce the burden and safety risk associated with the integration of our product in the wider system, the system properties of interest (reliability, availablilty, safety) must be driven from the top down and so the system designer/integrator must still ensure compatibility of our IP to achieve system goals – fundamentally as part of a requiremnets-led design process. the DXS GPU is an ASIL-B SEooC product, the premise of the tehcnical safety concept behind this is simply to detect and report errors which could lead to the violation of an overarching safety goal.

_{Asked by Satinder Paul Singh from Hermes Semi Conductors}

The actual safety implementation for automotive systems/SoCs depends heavily on specific customer use cases, whether the challenges arise at a system or item level etc., and are assocaited with a number of factors, some environmental, and some technical e.g. process node. The DXS IP does not enforce fixed configurations but offers scalable options for customers aiming for different ASIL targets. Architectural and physical safety techniques, such as ASIL decomposition and TMR (Triple Modular Redundancy), can be applied to manage risk appropriately. Ultimately, the goal is to provide flexible but robust solution that aligns with the target safety metrics and real-world application needs, allowing customers to make informed, pragmatic decisions based on their system design requirements.

_{Asked by Satinder Paul Singh from Hermes Semi Conductors}

Technically, DXS and its distributed safety archiecture is not making any formal cybersecurity resilience claims cf ISO 21434 or similar standard. The focus on this archeicture was predominatly safety, however, there are various inbuilt features developed to the systematic ISO 26262 standard which support cybersecuirty resilience endeavours, namely, HW Virtualisation, DRM, supported by internal MMU and MPU also. It would be fair to suggest that some of the safety control mechanisms would support cybersecurity goals, however, known vulnerabilities would be for the system integrator to manage depending on their risk appetite in their intended application. Imagination Technologies’ Product Security Policy is publicly available and as a Common Vulnerabilities and Exposures (CVE) Numbering authority, all GPU Vulnerabilities (CVE) are reported publicly – please see our website for more details.