AutoSoC Benchmark Suite - an Open-source Automotive Benchmark

Description

AutoSoC Platform

The AutoSoC is distributed as a set of configurable Hardware IPs (described in RTL), integrated into a System on Chip. The complete system is synthesizable. The synthesis compatibility was checked with the Cadence GPDK045 (45nm CMOS Generic Process Design Kits). Also, AutoSoC includes compatible Software applications compiled with RTEMS and Linux Operational Systems, and Bare Metal. The AutoSoC environment incorporates Makefiles and scripts to facilitate the configuration and simulation of the SoC.

The proposed SoC considered the main features available in well-known automotive platforms. The objective of this characterization was to create an SoC that is representative of the industry standards. Although different commercial solutions are available, in general, architectures have similarities that can be explored to define a set of requirements for an Automotive SoC.

Based on the characterization of industrial solutions, an initial architecture of AutoSoC was established. Functional blocks were defined aiming to cover the minimum set of features required for a representative automotive platform. The concept of functional blocks is also important to keep the design modular. Different versions of AutoSoC can deploy diverse hardware components to cover the requirements of each functional module.

Functional Modules

Safety Island -- Monitors systems correct execution, must fail last

  • CPU, Memories and Safety Mechanism

  • SW Stack for Safe Applications

Application-Specific Block -- Domain specif application

  • May include Audio, Video, Sensor In, Display, e.g. DSP, GPU

  • Runs dedicated software (if any), may include execution of “Application level” software on SMP cores with OS

Automotive Block -- Enables In-vehicle communication

  • e.g. CAN-Bus and FlexRay

Security Block -- Maintains integrity during boot and in mission

  • e.g. AES and DES crypto IP cores

Infrastructure Block -- General Peripherals and Debug Units

  • e.g. UART, JTAG, SPI and I2C

Interconnect Block

  • e.g. NOC, Bus, Crossbar, etc.

At the current development stage, the AutoSoC contains the minimum set of elements for Preliminary Functional Safety Analysis as reported in the article published in the IEEE VLSI Test Symposium 2020. The available configuration comply with the Functional Modules: Safe, Automotive, Infrastructure, and Interconnect. The Application Specific and Security Blocks, as illustrated above, will be developed in the next stages of our work.

As part of its modular concept, several configurations of the AutoSoC are possible by enabling different combinations of Safety Mechanisms. Details about setting up different configurations are described in Quick Start. Any new configuration can then be elaborated and simulated with the provided Makefile. Although any possible combination of components can be created, we have defined a conceptual group of initial configurations. These configurations are based on common SM combinations from industry solutions. Preliminary Functional Safety Analysis results are available in Publications and can be used as a Benchmark for Automotive SoCs aiming different Safety Integrity levels.

AutoSoC Configurations - Based on combination of Safety Mechanisms

AutoSoC SAFE Configuration

AutoSoC SAFE Hardware Architecture

Represents the essential elements for the Safe-related functionalities

  • Safe Island with Fault monitor

  • Interconnect

  • Automotive Bus Interface

Exposes a set of common safety mechanisms

  • On processors, memories, interconnect

Modular concept allows multiple configurations

  • HW/SW components can be selected by configuration files

Open-source

  • Includes all Hardware description files in Verilog (RTL)

  • Several Software applications with source code (C/Assembly)

Exemplary execution environment included

  • Based on state-of-art EDA tool flow (Cadence)

  • Elaboration, Simulation and Fault Injection Campaigns

Hardware Architecture

OrpSoC - AutoSoC base

Basic Hardware SoC

AutoSoC is based on the OrpSoC: an OpenRISC based SoC

Mor1kx – CPU Implementation

Testbench features

  • Software loading to Memory

  • GDB connection via JTAG (via telnet in Simulation)


Safety Mechanisms

AutoSoC Dual Core Lockstep implementation

Processor Safety Features

Dual-Core LockStep implementation (DCLS)

  • Only Main CPU drives the bus

  • Not splittable (single bus interface)

Time Diversity

  • All inputs to Shadow CPU are delayed by two clock cycles

  • Outputs from Main CPU are also delayed for comparison

Compare Unit

  • Error signal is set if outputs of the CPUs differ

AutoSoC - Safety Island for Automotive applications

Safety Island

DCLS Controller

    • CPU redundancy with time diversity

    • Shadow used only as Safety Mechanism

Parity Check

    • Verifies accuracy of data transmitted between CPU and Memory (bus transport protection)

ECC

    • Memory model with ECC

Checkpoint Controller

    • Watchdog with Software Control Flow capabilities

Safety Monitor

    • Monitors all Safety Mechanisms and provides debug information

Software Test Libraries (STL)

  • A set of software procedures deployed for on-line fault detection

Software Elements

AutoSoC Software Resources

Software Package

Baremetal

Linux

  • Bootable Linux image compatible with Simulation (boot+ramfs load)

  • Includes configuration files for new kernel builds

RTEMS

AutoSoC - Cruise Control Application based on RTEMS

Cruise Control Application

Sensor Task

  • Period: 50 ms

  • Receive Information from Vehicle sensors via CAN

Control Task

  • Period: 50 ms

  • Compute Throttle and Break parameters based on sensors and on Cruise Control configuration

Engine Task

  • Period: 50 ms

  • Transmit Throttle and Break configuration to Engine Control modules via CAN

House Keeping Task

  • Period: 200 ms

  • Configuration of Application

  • Monitor Software Execution via Watchdogs


* On the current version the Vehicle Sensor data is hard coded in the software