Upload
posy-russell
View
217
Download
1
Embed Size (px)
Citation preview
Fault Models and Injection Strategies in SystemC Specifications
ANTONIO MIELE
Dipartimento di Elettronica e [email protected]
Agenda
• Introduction
• Related work
• The considered simulator: ReSP
• Injection strategies
• Fault modeling
• Case studies
• Conclusions and future work
2
Introduction
• SystemC and TLM are the de-facto standard in HW/SW system specifications. Goals:
Simplify the design flow Increase simulation speed Allow an early evaluation of the system
• Even if there is an extensive literature for different aspects of the design and analysis of TLM specifications, little work has been done for reliability assessment
Need for new fault injection strategies to be integrated in the novel design frameworks
Need for suitable fault models for high level specifications
3
Goal
• Propose a fault injection and analysis tool as an extension of ReSP, a simulation platform for SystemC models targeted for multiprocessors systems design and analysis
Development of the necessary support within ReSP to ease the injection and the analysis
Definition of a fault modeling methodology for high level descriptions specified with SystemC and TLM
4
Related Work
• Many fault injection tools and strategies have been defined for VHDL descriptions
• Classical injection strategies: Mutants – the nominal component is replaced with an
instrumented one able to simulate the nominal and faulty behaviors
Saboteurs – a fault injection module is inserted on the line to be corrupted
Simulation commands – the simulation console provides features for modifying the value of the signals
5
Related Work (2)
• Few approaches for SystemC descriptions: [Fin et al. 2001] adopts the mutant approach for injecting faults in
descriptions at different levels of abstraction considering only the stuck-at fault for testing purposes
[Misera et al. 2006] proposes a multi-language framework exploiting saboteurs
[Chang et al. 2007] explores through some examples the injection at different levels of abstraction using saboteurs and analyzing controllability and observability
[Misera et al. 2007] investigates the three approaches in SystemC descriptions and, in particular, simulation commands proposing a patching of the SystemC kernel
6
Related Work (3)
• [Moraes et al. 2003] and [Martins et al. 2000] propose two frameworks for fault injection in Java and C++ models using simulation commands implemented by means of reflection features
• Background: Reflection (or introspection) is a feature offered by modern
programming languages such as Java or Python to discover, access and modify the structure of a program at runtime
E.g.:>>> dir(MyComponent)['port1', 'port2', 'register', . . . ]>>> getattr(MyComponent, 'register')3
7
ReSP Simulation Platform
• ReSP [Beltrame et al. 2008] is a simulator for hardware/software system specifications
Particularly targeted for transaction-level multiprocessor systems
• Built in SystemC and Python SystemC is the standard in hardware/software system
specification• C++ extended with hardware modeling concepts
• C++ execution speed
Python offers introspection and scripting capabilities• Offers a non-intrusive visibility on all the platform elements
• Run-time composition and dynamic management of the specification
• Provides an enhanced simulation control (asynchronous pause/resume commands)
8
ReSP Simulation Platform (2)
• Integration-oriented top-down design approach with a systematic reuse of IP cores
An IP repository is provided for building the system The designer can build the system by instantiating and connecting
components at runtime
9
• Advantages: Easy integration of new IPs Fine grain control of
system-level simulation Effortless development of
tools for system analysis and design space exploration
The proposed extension to the platform
• ReSP simulator has been adopted and extended for implementing a fault injection environment
Definition of fault models and injection strategies
10
• Required qualities: Transparency
• No instrumentation of the components’ descriptions
Dynamism• Definition and planning of the
fault injections at run-time
Independence from the system description
• In particular from the abstraction level of the descriptions
Injection strategies
• Simulation commands The simulation platform has been extended for providing injection
commands based on Python reflection and scripting
• Saboteurs Saboteur models have been included in the IP repository They can be instantiated and connected to the components of the
considered system
• Mutant approach is supported even if not considered due to its intrusiveness
However, mutants can be included in the IP repository
11
Injection strategies (2)
• In SystemC, components are C++ objects Component internal state (registers, memories, ...) is modeled
with object attributes (variables)
• Transient faults can be modeled as a value change in an object variable
• Simulation commands are implemented for transient faults by using Python reflection
Component methods and attributes can be retrieved with introspection
Object state modification is performed dynamically thanks to introspection and scripting
12
Injection strategies (3)
• E.g.:
• Saboteurs are used for injecting faults on interconnections
13
proc mem4 5
sab
Injection strategies (4)
• Permanent faults require a register or an interconnection to be blocked to a specified value
• Permanent fault strategy implementation as simulation commands are based on the event watching mechanism
Every time the faulty location is changed, it is updated with the faulty value
• Saboteurs are used for injecting permanent faults on interconnections
14
Analysis and Execution Strategies
• Interactive simulation mode: The user controls the simulation through the console enhanced
with asynchronous execution pause and resume
• Batch simulation mode: Fault injection campaigns can be performed
• Provided facilities: Automatic instantiation of saboteurs Automatic instantiation of golden models Generation and execution of fault campaigns Collection and analysis of results
15
Analysis and Execution Strategies (2)
• System execution monitoring: Step by step execution
• Execute for a while and analyze system status
Probes on interconnections• Monitor events on interconnections
Event watching mechanism• Monitor events inside the components
16
Case Study: simulation of fault tolerant architectures
• Four different fault tolerant versions of the same architecture have been considered for fault injection experiments
17
Loosely synchronized dual processor
Lock-step dual processor
TMR processor
Processor running hardened SW
Demo after the presentation…
Fault modeling
• Which corruptions of internal state and interconnections represent real physical misbehaviors?
• Definition of a methodology for modeling faults in IP descriptions modeled at the different levels of abstractions supported by SystemC
• IPs description can be provided as: TLM description
• It can be used “as is”
RTL description• It has to be abstracted to a TLM model
• This analysis focuses on SEU
18
SystemC and TLM Abstraction Levels19
• SystemC and TLM abstraction levels can be described in terms of computation and communication aspects
Mutation Models
• A mutation model identifies all the elements of the specification that can be manipulated to model the effects of a physical fault
• Mutation models have to be defined for each abstraction level
• The mutation model is the basis for the definition of a fault model
20
Mutation Models (2)
• RTL Every register of the circuit is represented in terms of object
attribute and all I/O are specified All actual fault locations can be accessed and corrupted
• BCA Core functionality is expressed algorithmically Mutation models are:
• Corruption of attributes that represent the internal state of the component between different elaborations
• Corruption of all I/O
21
Mutation Models (3)
• AT and LT Core functionality is expressed algorithmically Communication is expressed with blocking/non-blocking function
calls and standard data structures Mutation models are:
• Corruption of attributes representing the internal state of the component
• Interface function misbehavior:
22
Fault modeling
• The idea is to list the misbehaviors affecting the considered IP and represent them in terms of mutation models
Generation of a fault dictionary for each IP
• Fault modeling specifies how to use available mutation models Fault modeling gives a semantic meaning to the mutation models
• Two different approaches: IPs without RTL implementation
• Make assumptions during analysis due to the lack of implementation details
IPs with RTL implementation• Define and abstract all physical misbehaviors
23
Fault modeling without RTL implementation
• The fault modeling strategy relies on assumptions on the possible misbehaviors
• Misbehaviors are derived from the analysis of the LT (or AT) specification Three main aspects have to be considered:
Component attributes• Can be corrupted according to their actual domain
Interface functions• Can be mutated as previously described
Functional algorithmic description• Each basic task composing the algorithmic description is mutated as:
– The task is not erroneously executed– The task is executed when not requested– The task is not executed
• The obtained fault models can be refined with the available information on the implementation or on the synthesis process
24
Fault modeling with RTL implementation
• A complete taxonomy of physical misbehaviors can be defined for the RTL model and abstracted to LT (or AT) level
• During component abstraction, we keep track of how fault locations (i.e., storage elements) change between abstraction levels
• Computation abstraction: Registers used for storing data among different elaborations are
mapped on component attributes Registers used for storing data in the same multi-cycle elaboration
are removed since elaboration is performed atomically
• Communication abstraction: Registers used for multi-cycle communication protocols are
removed since transactions are executed atomically
25
Fault modeling with RTL implementation (2)
• Fault modeling: Registers used for storing data among different elaborations are
mapped on component attributes
Corruption of attributes
Registers used for storing data in the same multi-cycle elaboration are removed since elaboration is performed atomically
The effects of the faulty functionality on the component internal state and output represented with the available mutation models
26
Fault modeling with RTL implementation (3)
• Fault modeling: Registers used for multi-cycle communication protocols are
removed since transactions are executed atomically
The effects of the faulty communication in terms of mutation models
27
Case study: the NoC switch
• An LT model of a NoC switch has been considered 5 I/O directions Alternating Bit Protocol used for flow control Data transmitted in units called flits (header, body and tail)
• Fault modeling on the LT description: Attributes can be corrupted according to their domains
• std::queue<struct flit> buffers[5]
• int reservation[5]
• int next
The control flow RTL implementation is analyzed and faults abstracted• Only phantom and fake calls corresponds to physical failures
Two functions representing receiving and transmission can be behaviorally corrupted
• An RTL model has been implemented and categorized in terms of faults
28
Case study: the NoC switch (2)
Two functions representing reception and transmission can be behaviorally mutated
29
Case study: the NoC switch (3)
• An RTL description of the circuit has been implemented:
• Results: RTL contains 1798 fault locations:
the corruption of only 30 are not represented by fault models 23 fault models have been defined for LT model:
14 are effective, 7 redundant and only 2 do not correspond to any physical misbehaviors
30
Conclusions and Future Work
• A fault injection environment has been implemented as extension of ReSP simulation platform for SystemC/TLM specifications
• A fault modeling methodology has been proposed for SystemC/TLM specifications
• Future work:• Adoption of the fault injection environment and the fault modeling
methodology for the definition of a methodology for reliability assessment of SystemC/TLM specifications
31