Safety Verification and Software aspects of Automotive SoC

Safety Verification and Software aspects of Automotive SoC
IP-SoC Conference 2017
Pankaj Singh, Ranga Kadambi, Kirankumar Bandlamudi, Dinesh Selvaraj

Copyright © Infineon Technologies AG 2017. All rights reserved. 22017-10-02
Level 0
Level 4
Level 5Adoption
Source: NHTSA
"The data tell us that people die when they drive drunk, distracted, or drowsy, or
if they are speeding or unbuckled," said NHTSA Administrator, Dr. Mark Rosekind.
“The nation lost 35,092 people in traffic crashes in 2015, ending a 5-decade trend
of declining fatalities with a 7.2% increase in deaths from 2014”
As the industry moves to Autonomous driving, Fatality
should reduce significantly
Quality of Software is important as driving tasks traditionally entrusted
to human drivers will now be delegated to Software.
Functional Safety is critical for Autonomous driving to avoid hazardous
situation
Quality of Software and Compliance to Functional Safety

Copyright © Infineon Technologies AG 2017. All rights reserved.
3
ISO 26262 compliant product development
2017-10-02
In the presence of random hardware faults:
1. Verify compliance of design with safety requirements
2. Quantify diagnostic coverage of safety mechanisms
Functional
Simulation
Fault injection
Simulation
Safety analysis

Systematic & Random Faults
Systematic Fault
Systematic Fault
Random Faults
1.DC Fault model(Stuck@/Bridging)
2.Soft Error (Transient, SET/SEU)
Fault injection can be at 2 abstract levels:
1. Qualitative: Evaluates the failure mode effects and
reaction time.
2. Quantitative: Evaluates the diagnostic coverage of the
safety related hardware.
DUT
Safety
Mechanism
Design
Functionality
SW
HW
Reference image: CDN
42017-10-02

Copyright © Infineon Technologies AG 2017. All rights reserved. 5
Qualitative and Quantitative Fault Injection Comparison
2017-10-02
SN Qualitative Quantitative
1 • Carried out with RTL. • Carried out with Post layout Netlist
2 • Failure Modes, its effects and its
detection is verified.
• Fault nodes are hand-picked
• Fault node selection is statistical in nature
3 • Qualitative Failure mode Coverage • Safeness fraction and Diagnostic coverage
is determined which is used in the
calculation of safety metrics
4 • Extraction of Fault Detection Time • Fault detection time is not in scope
5 • Single / Multiple Stuck-at and
Transient analysis
• Single Stuck-at, Transient and Bridging
analysis

Improvements in EDA Landscape
EDA Landscape then EDA Landscape Now
1 Support for Verilog-95 only, older versions of PLI(s) -
Models required to be re-written.
Supports all HDL - No need to write models in specific
HDL
2 No support modern HVL – No Reuse of Existing HVL Test
benches
Supports modern HVL - Re-use functional verification
environment.
3 Hyper-activity - Due to concurrent algorithm, any hyper-
activity halts the total fault simulations.
No simulation stalls due to hyper activity (due to
sequential algorithm)
4 1 kind of strobe - Requires 2 sequential fault simulation
sessions to evaluate safety metrics.
2 kinds of strobes (functional and checker) - Coverage
Metrics can be derived with in one session
5 No support for transient faults Support transient fault models - One simulator for both
stuck-at and transient analysis
6 Limited/no debug features - Huge effort in analysis Debug features same as State-of the art - Ease of
analyses and debug resulting in Quick turn around time
62017-05-16 Copyright © Infineon Technologies AG 2017. All rights reserved.

Results of Qualitative Fault injection
› Clock Generation Logic
– A ‘Configuration Register’ Controls the ratio of the clock frequency compared
to the source.
– A ‘Count Register is used to measure the deviation against a reference.
› Following example to illustrate, what happens
– With stuck-at fault (Stuck@)
– With transient fault (SEU)
› 2 example cases are considered for each
– Error happened on ‘Configuration Register’
– Error happened on ‘Count Register’ (that generates enable signal)

Results: Data path
‘Configuration’ Register
‘Count’ Register
Test Scenario to
activate the Failure
Mode:
• Set clock frequencies
• ‘Configuration Register’
Value = 2
• Expect fsource/2 on clk_o
• Wait for some time
(random)
• Perform an update on
‘Configuration Register’ =
2
• Expect fsource/2 on clk_o

Results: Stuck@1 – Configuration Register
Stuck@1 error on bit[16] of
Configuration Register. Changes ratio
from 2 -> 3
System update the configuration
Register = 2. but the value is
still 3, due to stuck-at

Result: SEU - Configuration Register
SEU error on bit[16] of configuration
register. Changes ratio from 2 -> 3.
clock frequency changes
System update with spbDiv = 2.
brings back spbDiv state to 2.

Result: Stuck@0 - Counter Register
System Update on Configuration
Register will have NO impact on this

Result: SEU - Counter Register
Pulse missing Extra Pulse
SEU error on counter register. Bit flip
cause EN to 0 -> resulting in missing
pulse. Subsequent clock cycle, state is
brought to correct state
SEU error on counter register. Bit flip
cause EN to 1 -> resulting in extra
pulse. Subsequent clock cycle, state is
brought to correct state
Test Scenario activates Failure Modes.
Safety Mechanism detects these faults and takes action in stipulated time

Report of the Qualitative Fault Injection

Quantitative Fault Injection Flow Overview

Statistical Fault sim on SHE+ : SW Safety Mechanism
 FMEDA shown >99% safeness.
 Objective is to confirm this using statistical fault
simulations.
 0.12 millions faults are injected (using IFSS)
 16 false positives are found. Root cause for all 16
are found. This will be reflected in safety manual
Software has incorporated several safety mechanisms to detect false positives in the presence of HW fault
15

Comparative investment in Autonomous Driving
Most of the Innovation and Investment is in Autonomous
Driving . Key differentiator for Autonomous driving is Software
162017-10-02
https://www.cleantech.com/how-autonomous-vehicles-drive-technological-innovation/

SW Validation Flow –Left Shift.
Synchronized H/W and S/W in SOC
172017-10-02
Concept Engineering
Micro Architecture
Hardware
Software and System Integration
Concept Engineering
Micro Architecture
Hardware
Software & System Integration
Virtual Prototype
Concept Engineering
Micro Architecture
Hardware
Software & System Integration
Virtual Prototype
Emulation
Timeline
Past: Sequential HW-SW Development
Current: Parallel HW-SW Development
using VP
Planned: HW-SW System Development using VP &
Emulation
Co-
verification
Virtual Prototype
(VP)
LowLevelDriver
(LLD)
Integrated
VP+LLD
release
AUTOSAR Base/
App SW
Development
System
testing
RTL IP/SS design
SoC
Verification
Silicon
Tapeout
Post Silicon
Validation
Validation tests
preparation
SoC tests
preparation
Emulation
SW Design
HW Design
Concept
Current: Parallel HW-SW Development
using VP
Synchronized HW and SW Functional Verification
helps achieve Quality, Cost , time to market in scope

Evolution of VP Technologies and ESL tools
18Copyright © Infineon Technologies AG 2016. All rights reserved.2017-10-23
C++
1. VPs were developed in pure C++ until 2005
2. Critical limitations in modelling hardware like no parallel
process, no notion of time, no support for all logic states, etc
3. Semicons having their own simulation kernel
SystemC:
1. A C++ library available for free. IEEE standardization by 2008
2. Offers light weight simulation kernel, process, HW data types,
communication channels, etc
3. Widely recognized as system modelling language
TLM2.0:
1. Best suited to abstract memory mapped bus interface
2. Interoperability among different suppliers
3. Offers both Loosely and Approximately timed abstractions
In-house
integration
flow
(Manual coding)
Birth of ESL
Integration
using Drag-drop
in GUI or scripts
More standards like CCI, Portable Stimulus, UVM-SC
Consolidation
of ESL tools
(Improved
feature and
performance)

Improvements in ESL Landscape
ESL Landscape Then (early 2000) ESL Landscape Now
1 Model development is tool dependent and each vendor
promotes different modeling standards and simulation
kernel
SystemC/TLM2.0 becomes standard across all vendors as
base kernel with minor updates. No impact for model
developers
2 IP Model development from scratch that delays the VP
integration
Huge IP model portfolio to shorten VP integration
3 Limited in-built debugging options Intrusive tracing and monitoring that makes debugging
easier
4 In Compatibility with third partly tools Native support for co-simulation with third party tools
5 No native support for fault injection Moderate support for fault injection

Use cases and Fault injection using VP
2017-10-02
Chip
Supplier/
Tool
Supplier/
Tier 1/OEM
SW
Functional
Validation
Silicon
Validation
tests
preparation
Fault
Injection
Tests
SW Code
coverage
SW
performance
analysis
Automatic
SW
Regression
testing
CPU0
Primary XBAR
Flash Bank 0
Bridge
SMU
Peripheral Bus
SCU
Regular
SW
Error
Handler
• Monitor
flash read
• Wait for
a specific
address
• Trigger
SMU alarm
and set
ECC error
bits
SMU Alarm
Trap
generation
request
CPU Trap
SW Trap Handler
Data flow for validating SW error handler for Flash ECC
• In general, ECC is not supported in VP
• Alternate script mechanism or Instrumentation is used to trigger such error
• Assume ECC failure is expected while reading a particular data flash range
20

Copyright © Infineon Technologies AG 2017. All rights reserved. 21
› Quality of Software and Functional safety are critical for success of
Autonomous driving.
› Safety is now an integral part of Automotive IP and SoC.
– Fault Injection Methodology is recommended by the ISO26262.
– Functional Safety should be looked from H/W and S/W perspective.
› Synchronized HW and SW Functional Verification helps achieve Quality,
Cost and Time to Market within scope.
2017-10-02

THANK YOU!
Any Questions

Safety Verification and Software aspects of Automotive SoC

More Related Content

What's hot (20)

Similar to Safety Verification and Software aspects of Automotive SoC (20)

More from Pankaj Singh (10)

Recently uploaded (20)

Safety Verification and Software aspects of Automotive SoC