a thesis submitted for the degree of Dr.-Ing. SystemCThrough the Looking Glass: Non-Intrusive Analysis of Electronic System Level Designs in SystemC by Jannis Stoppe Supervisor: Prof. Dr. Rolf Drechsler Second referee: Prof. Dr. Stefan Edelkamp CONTENTS 1 introduction and motivation 1 2 preliminaries 7 2.1 Hardware Design Approaches 8 2.2 SystemC 13 3 extraction of systemc meta data 19 3.1 State of the Art 20 3.2 Debug Symbol Parsing 27 3.3 Extraction of Static Information via Debug Symbols 28 3.4 Extraction of Dynamic Information 31 3.5 Conclusion 39 4 extraction of systemc behaviour 41 4.1 Software-Based Approaches 42 4.2 Consecutive Snapshot Extraction 46 4.3 Compiler-based Behaviour Modification 48 4.4 Aspect-Oriented Analysis Insertion 50 4.5 Conclusion 62 5 filling the gaps with machine learning 65 5.1 Reverse-Engineering Module Logic 69 5.2 ESL-specific Additions 73 5.2.1 SystemC’s modularity 74 5.2.2 Time of extraction 75 5.2.3 Time delays 77 5.2.4 Internal states 78 5.2.5 User-defined datatypes 79 5.2.6 Circles 80 5.2.7 Summary 80 5.3 Conclusion 82 6 application 83 6.1 Visualization 84 6.1.1 Previous Work 85 6.1.2 Realization 87 6.2 Cone of Influence Extraction 91 6.3 Feature Localization 94 6.3.1 Previous Work 95 6.3.2 Realization 98 6.4 Validation of FSL specifications 100 6.5 Stimuli Generation via Machine Learning 102 iii Contents 6.5.1 Previous Work 103 6.5.2 Applying Machine Learning for CDSG 104 6.6 Conclusion 106 7 conclusion 107 iv DISCLAIMER I hereby declare that • this dissertation is my own original work, • it has been completed without claiming any illegitimate assistance and • I have acknowledged all sources used (both, verbatim and regard- ing their content). Jannis Stoppe, February 27, 2017 v I would like to thank Robert Wille for the assistance he offered whenever I needed it and the time he put into me and Rolf Drechsler for enabling me to present my ideas to the world and giving me the opportunity to work in a beautiful environment. Your support has been invaluable. I would also like to thank my wife and children for being a patient, loving support during stressful times. You give meaning and make me endure, which is more than I ever could have hoped for. 1 INTRODUCTION AND MOTIVATION We can only see a short distance ahead, but we can see plenty there that needs to be done. Alan Turing [113] The complexity of digital systems is increasing. Ever since Gordon E. Moore projected that the amount of components in integrated circuits would double every year in 1965 [75] (and later revised that to every two years in 1975 [76]), his prediction would hold. This exponential growth not only leads to faster and more complex sys- tems, it also results in serious issues concerning their design: A current 18-core Intel Haswell Xeon chip consists of more than 5 billion transis- tors [79] – nearly twice as many as there are base pairs in the human DNA [115]. Being able to manufacture such large systems, while being an impres- sive achievement by itself, still requires them to be designed in the first place. This simple aspect is a serious problem for the development of modern chips as the design tools must enable the designers to handle such large systems: if these large systems cannot be designed, they can- not be manufactured. Classic Hardware Description Languages (HDLs) that have been de- signed to model hardware are – by definition – close to the hardware they describe. This also means that systems that are written using these HDLs cannot easily be run and/or tested if the description is still incom- plete. Thus, the development process becomes a bottom-up approach, requiring designers to first build the system as a whole and then start testing it. Issues with the overall architecture can therefore only be found once the system has been fully implemented, making decisions that need to revise architectural properties expensive and thus large sys- tems tough to be designed. Traditional HDLs hence struggle with the complexity of modern hard- ware. In order to keep up with the manufacturing advances, the designs are following a modular approach and the distinct parts are re-used. Es- pecially in conjunction with well-scaling parts such as memory (which can simply be “made larger” in order to gain the according benefits), these larger designs can still be achieved – at least to a certain degree. Still, complexity remains a key issue, especially for designs that cannot be scaled easily or do not benefit from such a scaling. HDLs are there- fore increasingly facing the issue of the design gap [35], i.e. the problem 1 introduction and motivation that systems cannot be designed in accordance to the available manufac- turing capabilities due to their complexity. In order to handle this complexity, more abstract description lan- guages have been introduced. These so-called system level descriptions are used to model the coarse structure using established features (such as modules and signals) but use an underlying high-level programming language (such as C++) to describe the detailed behaviour of these parts. This means that a system can be prototyped more quickly and the system as a whole may be tested before the actual hardware (or software) parts have been implemented. The current de-facto standard for system level design is SystemC [7]. Implemented as a C++ library and specified in an open standard [81], it combines the benefits of an established high-level programming lan- guage (such as tool chains, libraries, Integrated Development Environ- ments (IDEs) etc.) with the ability to describe hardware designs on an abstract level and simulate them despite being implemented in this ab- stract way. Although these system level languages strive to reduce the amount of complexity needed to create a prototypical system design, the designs still are considerably complex. To appropriately model all parts of a sys- tem and their interactions, the design usually becomes quite large, even when working on higher levels of abstraction. The sheer size of a de- sign may make it difficult for new designers to join a project. Acquiring knowledge about a design, either to introduce new members into a team or to keep other people working on the project up to date with recent changes, is therefore a critical part of the design process. This Design Understanding can be approached in a variety of ways, de- pending on the available sources of information. Reading the source code of the design is usually inefficient and not an appropriate way of starting to understand a design, especially for larger designs. While a proper (manually created) documentation is usually the best way to introduce designers to certain parts of the work, the creation and es- pecially maintenance of a manual is a time-consuming (and therefore expensive) process with no immediate benefit for a project, making it sometimes infeasible to keep the documentation in an appropriate con- dition. Methods to automatically generate or retrieve more abstract represen- tations of hardware designs to allow designers to quickly grasp impor- tant structures are one way to approach the problem of imperfect, man- ually created meta documents. The automatic generation of e.g. visual representations of system designs is a common way to quickly allow designers to take a glance at a system’s general structure. While this ap- proach of course needs to address issues such as the complexity of the resulting images [45] or the performance of the visualisation [58, 128], 2 introduction and motivation deriving the structure to be displayed from the source code has been a straightforward procedure for classic HDLs. System level descriptions in general and SystemC implementations in particular level descriptions are, however, harder to analyse. The hardware structures are not described statically as in classic HDLs but instead are created dynamically at run-time, making a static analysis ap- proach to extract the structure more difficult or even impossible. Addi- tionally, C++ is an older language with lots of different dialects available that is not even considered context-free. This means that writing a single parser that could serve as a front end to analyse a design is an equally futile task. Lastly, compilers are used to translate the system descrip- tions into an executable form – in case of C++ binary code which can directly be executed on a given computer. This means that once the pro- gram has been processed to be executable, it is even harder or downright impossible to analyse. This work proposes new methods and approaches to analyse SystemC designs despite these issues and without shifting the burden to the de- signer (by e.g. requiring the source code to adhere to certain standards). More precisely, the research question of this thesis is How can the desired information from a given SystemC design be extracted without assuming restricted language means and with- out modifying the existing infrastructure like parsers or compilers? This means that there are two core requirements to any solution. The first is that the source code should be considered untouchable. If the solution to the analysis problem is anything that requires major source code alterations, the designers may as well simply add the required trac- ing functionality to their code without utilizing another solution. As the time required to use a solution can be directly translated to the money that an engineer needs to be paid, the solution must be easily added in order to prevent large costs for something like an analysis tool.