Autonomous Vehicles require safety-critical processing of information. Power Architecture processors have dominated safety-critical processing since the late 1990s, when major processing suppliers exited the MIL-qualified and/or aviation-certified markets. Since that time, four trends have emerged:
Military and commercial safety certification has become more rigorous
Server/desktop architectures have focused on performance at the expense of determinism
System-on-Chip (SoC) architectures are offered, with multiple processing cores (multicore) in a single package to increase performance over single-core processors
The industrial automation industry is increasing safety requirements for autonomous manufacturing, and the automotive industry is offering driver assistance, including autonomous operation, creating a large market for relatively low-power, high-integrity processing
Although the Power Architecture will remain a viable safety-critical processor technology for some time, new industrial processing products and architectures are poised to enter (or re-enter) the markets of safety-critical processing. Safety-critical processing markets of different industries require the following similar capabilities:
Longer product availability lifetimes (5-15 years) than consumer/server-grade processors
Low power draw
Extended temperature operation
High safety integrity
This CRC Press News introduces the microprocessor industry support and certification issues. High-level activities to bring safety critical products using Multi-Core Processors (MCPs) are also discussed, based on current industrial MCP development, with all cores operational, supporting Design Assurance Level (DAL)/Safety Integrity Level (SIL)/Automotive Safety Integrity Level (ASIL).
Industrial suppliers are currently at a crossroads where new processing products are offered in SoC and MCP packages and alternative computing architectures are challenging the Power architecture. The initial investment to provide certifiable products employing MCPs can easily cost more than $10M, which makes processor choice important. Thus, the modern industry is faced with a decision to continue with the Power architecture products, which have reliably served the safety-critical industries for nearly two decades, or specify potential competitors such as x86 and recent A-core ARM MCPs.
The focus of this CRC Press News is on medium power (15-45W), medium-high performance processors that provide that performance by using multiple cores.
This CRC Press News doesn’t pick a winner as there probably isn’t a single solution for all industrial applications, and at this time there remain many activities underway by MCP suppliers that will affect trade studies.
However, this CRC Press News does describe the hurdles in bringing a new computing architecture to markets in industrial products, and describes alternative MCP supplier’s interest and plans for the industrial markets.
Faced with little opportunity to increase processing power of Single-Core Processors (SCPs), processor suppliers increase performance by providing multiple cores in a single package. When software applications share resources potential resource contention exists that must be solved for deterministic safety-critical systems. This condition is called an interference channel. “Virtual Machine” software partitioning solved application-application resource contention on SCPs in the late 1990s. Today the use of software partitioning in safety-critical systems is widespread, and this integrity technology is extended to MCPs.
MCP architectures complicate interference mitigation strategies by adding another layer of potential contention (core-to-core) in the architecture. In this case, the MCP supplier provides contention arbitration mechanisms, not the integrator. This means that for safety-critical MCP applications, the integrator must have more intimate knowledge of machine-level arbitration than in the case of SCPs, and that knowledge must be provided by the MCP supplier.
Take th he QorIQ T2080 internal architecture as an MCP example to demonstrate interference channels.
The T2080 MCP includes four Power e6500 cores that can be dual-threaded as Thread 1 and Thread 2 (T1 and T2).
Each of the four e6500 cores has dedicated data and instruction caches.
If dual-threading is enabled, an interference channel exists for threads sharing L1 cache memory on the same e6500 core.
If dual-threading is not enabled, no L1 cache interference channels exist which simplifies the interference mitigation strategy.
However, the L2 cache is shared by the four cores, so an interference channel exists there.
Other areas of potential contention are external memory access through the shared memory controller and Input/Output channels. The Coherency Fabric provides resource access arbitration mechanisms.
Let’s discuss a notional MCP software architecture. Three core configurations can be implemented on four cores or more in a MCP package. Application software executes in Virtual Machines (VMs) that are enabled in two ways,
virtualized by a hypervisor, which configures and initializes the VMs then recedes into the background, only to respond to exceptions, and
by partitioning provided by Guest Operating Systems (GOSs).
The hypervisor and GOS products are typically provided by a 3rd-party supplier, and other “foundation software” such as Board Support Packages (BSP) and software drivers are typically developed by the integrator.
A hypervisor or virtual machine monitor (VMM) is computer software, firmware or hardware that creates and runs virtual machines.
A computer on which a hypervisor runs one or more virtual machines is called a host machine, and each virtual machine is called a guest machine.
In this notional MCP software architecture, the hypervisor and low-layer BSP and driver software are common to all cores, however the integrator can select a Guest Operating System (GOS) that minimizes impact to existing application software, which can greatly reduce application software porting costs.
Other software architecture examples may include an OS that integrates hypervisor and GOS together. While there are advantages to these types of products, they may not support GOS products from other suppliers.
For Autonomous Vehicles’ applications, three possible core configurations are:
The Core 0 GOS components support ISO 26262 partitions.
The other cores rely on the hypervisor to provide partitioning.
The processing space within each partition is statically allocated processing, memory and I/O resources, and is called a Virtual Machine (VM), since the application software running within a partition has no knowledge of any other application executing on the same core.
The Core 1 has a single partition with a General Purpose GOS, such as Linux, as an example.
Core 2 configuration has a separate GOS in each of the partitioned Vms.
While partitioning improves software modularity and coupling (good things), the real motivation for partitioning is reducing certification costs of application software through hard separation and guaranteed availability of required resources (memory, space, time, and I/O resources).
SoCs and MCPs are much more complex than partitioned single-core devices due to increased contention for shared resources such as cache memory and system memory, I/O and internal communications. Complex SoCs require additional safety engineering rigor, and MCPs have other additional considerations for safety-critical applications.
Current automotive processors demonstrate very high levels of safety integrity, availability and reliability to comply with the ISO 26262 functional safety standard. However, with the advent of autonomous vehicles and the expected reduction of mechanical controls in favor of electronic subsystems that execute ever more complex software, there will be a growing need to improve on these functionalities, especially to reduce system downtime and achieve fail-functional capabilities.
PC and server-class processor computing performance is achieved by integrating multiple processing cores into a single package. The multiple cores share some level of resources that affect determinism while generally providing higher performance.
Compared to Single-Core Processors (SCPs), MCP integrators are more reliant on supplier-provided MCP information to understand internal resource contention (interference channels) and how the MCP arbitrates contention.
As an example, ARM and X86 are currently providing products to the automotive market from two diverse directions,
X86 from desktop/server markets where processors are selected on computing performance; and
ARM from the embedded/battery-powered market, where low power consumption is paramount.
ARM and x86 currently support the automotive industry which has increasing need of high-integrity operation, longer product availability periods, and extended temperatures, all desirable for autonomous vehicles’ applications. In addition, the automotive industry has developed safety guidance including specific guidelines for application of Functional Safety, enabling state-of-the-art semiconductors technologies for Autonomous Vehicles.