Cloud native EDA tools & pre-optimized hardware platforms
Virtualization --the process of abstracting physical hardware by creating multiple virtual machines (VMs) with independent operating systems and tasks – has been around since the 1960s in the world of computing. Now, virtualization is coming to power- and area-sensitive embedded systems like automotive, motivated by the need to optimize the utilization of large AI and DSP blocks in automotive SoCs, and the need for increased functional safety in autonomous driving.
There are two recent truths about artificial intelligence in automotive embedded systems. The first is that the urgency to add artificial intelligence into embedded designs continues to grow. This is driven by numerous factors – the rapid pace of AI research resulting in expanding use cases, the increased number of cameras and other sensors in automotive systems, the increases in image resolution of those cameras and sensors, the impressive capabilities for AI over previous solutions, and AI’s position in the hype cycle helping drive new research as well as business case enthusiasm. The second truth is that the neural networks required to implement AI are computation hungry algorithms requiring large amount of area for all the multiply-accumulate (MAC) units needed to reach L2+ and beyond performance levels. As neural processing units (NPU) become a larger part of automotive SoCs, system designers want to make sure they are optimizing that resource.
Virtualization allows expensive hardware to be shared between multiple VMs by abstracting physical hardware functionality into software. Without virtualization, resources can only be assigned to one operating system at a time which risks wasting resources if one operating system cannot use all the resources of the physical hardware’s power.
Figure 1: Hypervisor software separates the physical hardware (processor HW) from virtual machines
As the demand for autonomous vehicles increases, so too does the need for ensuring the safety of those vehicles. The ISO 26262 standard defines functional safety (FuSa) requirements for detecting systematic and random (permanent and transient) faults for various Automotive Safety Integrity Levels (ASILs). forward collision warning or engine control functions will require a higher ASIL level than, say, managing the car’s entertainment system. Different tasks can require different FuSa quality levels.
Virtualization can guarantee freedom of interference between applications and operating systems of different quality levels running on a shared resource. Separating tasks that require higher ASIL levels from tasks that don’t require an ASIL level, makes the system more composable (modular) which simplifies the task of certifying your automotive system. Certification is required to verify your hardware has met the appropriate automotive standards. Each safety-critical VM and the hypervisor software will need to be certified. Non-safety critical VMs do not need to be certified, but they must be guaranteed not to break certified software.
Virtual machines include less downtime – critical in automotive – as multiple redundant virtual machines can be run alongside each other. An additional benefit of virtualization for autonomous vehicles is the ability to recover from safety errors. If VM1 is running a safety-critical task and VM2 is not, then a fault on VM1 could be ‘recovered’ if VM1 takes over the resources of VM2 to prioritize the safety-critical task.
Figure 2: Synopsys NPX6 NPU IP family supports virtualization in hardware and software
Figure 3a: Example of an NPX6=64KFS with no partitioning. External IOMMUs are integrated with the NPX6-64KFS which has sixteen 4K MAC cores for neural network computing.
Figure 3b: The NPX6-64KFS partitioning into two virtual machines.
Figure 3c: The NPX6-64KFS partitioning into three virtual machines.