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.
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.
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
AutoSoC is based on the OrpSoC: an OpenRISC based SoC
SoC cores source (https://github.com/openrisc/orpsoc-cores)
Mor1kx – CPU Implementation
CPU source (https://github.com/openrisc/mor1kx)
32/64-bit RISC architecture
OpenRISC 1000 ISA
2 to 6 configurable Pipeline stages
Single/Dual port RAMs
Testbench features
Software loading to Memory
GDB connection via JTAG (via telnet in Simulation)
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
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
Baremetal
Set of test applications for the mor1kx CPU. Based on source (https://github.com/juliusbaxter/mor1kx-dev-env)
BSP tailored for AutoSoC. Includes a Makefile for development of new applications.
Cross-compiler install instructions (https://openrisc.io/newlib/building.html)
Linux
Bootable Linux image compatible with Simulation (boot+ramfs load)
Includes configuration files for new kernel builds
RTEMS
RTEMS cross-compiler install instructions (https://docs.rtems.org/branches/master/user/start/index.html)
Example applications built for AutoSoC. Based on (https://github.com/RTEMS/examples-v2)
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