3 Performance and Usability Issues
The interception library has been coded in a C++ object oriented style. This makes the specialization of the wrappers very easy through inheritance. The library has less than 2.000 lines of code as shown in table 1 along with the amount of code that is compiler dependent.
The source code of TLM2 Wrapper Library V1.0 can be found at https://dl.dropbox.com/u/19987939/TLM2Wrapper.zip. The usage example distributed in the main module defines just two TLM2 modules and binds them in the usual way. After that a pass-through TLM2 wrapper is instantiated and the wrapper is inlined in the original transaction path. After invoking all TLM2 primitives, wrapper is ...view middle of the document...
A series of 1.000 calls to b transport target method were made using the following two configurations:
• Use of an interposition module between initiator and target.
• Use of virtual table hooking to interpose a method wrapper in transaction path using the C++ library
presented in this paper.
Given a TLM2 model, the introduction of any interposition code always introduces some time penalties. Even more if extensibility is design concern. The results show that virtual table hooking used by the interception library introduces a time overhead close to but lower than that obtained with an interposition module. Other important point to consider is that with this technique, only the specific desired call is intercepted while the other calls of the TLM2 interface run in the usual way. Using an interposition implies that all methods of the socket interface are intercepted and thus delayed. In the case of the virtual table hooking wrapper, it can be inserted and removed at runtime. Other improvement of virtual hooking method is that it can be applied to a single object instance instead of a class. This concern is exploited in the library usage example described in section 4.
4 Inline wrapper Library Fault Injection Use Case
This section presents a real testing scenario of the ICU’s boot software using Leon2ViP virtual platform and the TLM2 wrapper insertion library. Since the internal architecture of the Leon2ViP virtual platform is not the main focus of this paper, Figure 8 just shows only the main components, stressing the location of the fault injection wrappers:
• LEON2 ISS: SPARC V8 untimed Instruction Set Simulator with blocking TLM2 transaction interfaces.
• Memory: PROM, EEPROM and SDRAM blocks. The memory layout is highly configurable through an external configuration file and the current contents can be read from an external ordinary binary file generated by the compiler toolchain.
• Bus: This module interconnects all the TLM2 components of the virtual platform.
• SpaceWire: Virtual SpaceWire IP core for spacecraft communications. This interface can be mapped onto
a SpaceWire monitor or an external SpaceWire hardware based on a Star-Dundee USB SpaceWire brick .
For controlling the software execution, Leon2ViP offers a command-line interface with which the user can issue commands for loading memory binaries, for inspecting the internal state of the processor and the memory blocks and for defining breakpoints/watchpoints, among many others. SDRAM and PROM areas are usually filled with external program binary files using a load command. Leon2ViP also emulates EEPROM areas, the memory contents of these areas are filled at the system start-up with the contents of a file which has the same name as the memory block. The file should have the same size as the memory block and must contain its binary image. When the...