Fault Models and Injection Strategies in SystemC Specifications ANTONIO MIELE Dipartimento di Elettronica e Informazione

1. Fault Models and Injection Strategies in SystemC Specifications ANTONIO MIELE Dipartimento di Elettronica e Informazionemiele@elet.polimi.it

2. Agenda 2 • Introduction • Related work • The considered simulator: ReSP • Injection strategies • Fault modeling • Case studies • Conclusions and future work

3. Introduction 3 • 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

4. Goal 4 • 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

5. Related Work 5 • 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

6. Related Work (2) 6 • 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

7. Related Work (3) 7 • [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

8. ReSP Simulation Platform 8 • 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 • SystemCis 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)

9. ReSP Simulation Platform (2) 9 • 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 • Advantages: • Easy integration of new IPs • Fine grain control of system-level simulation • Effortless development of tools for system analysis and design space exploration

10. The proposed extension to the platform 10 • ReSP simulator has been adopted and extended for implementing a fault injection environment • Definition of fault models and injection strategies • 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

11. Injection strategies 11 • 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

12. Injection strategies (2) 12 • 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

13. Injection strategies (3) 13 • E.g.: • Saboteurs are used for injecting faults on interconnections 4 5 proc sab mem

14. Injection strategies (4) 14 • 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

15. Analysis and Execution Strategies 15 • 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

16. Analysis and Execution Strategies (2) 16 • 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

17. Case Study: simulation of fault tolerant architectures • Four different fault tolerant versions of the same architecture have been considered for fault injection experiments Loosely synchronized dual processor Lock-step dual processor Processor running hardened SW TMR processor Demo after the presentation…

18. Fault modeling 18 • 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

19. SystemC and TLM Abstraction Levels 19 • SystemC and TLM abstraction levels can be described in terms of computation and communication aspects

20. Mutation Models 20 • 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

21. Mutation Models (2) 21 • 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

22. Mutation Models (3) 22 • 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:

23. Fault modeling 23 • 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

24. Fault modeling without RTL implementation 24 • 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

25. Fault modeling with RTL implementation 25 • 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

26. Fault modeling with RTL implementation (2) 26 • 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

27. Fault modeling with RTL implementation (3) 27 • 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

28. Case study: the NoC switch 28 • 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

29. Case study: the NoC switch (2) 29 • Two functions representing reception and transmission can be behaviorally mutated

30. Case study: the NoC switch (3) 30 • 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

31. Conclusions and Future Work 31 • 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