Data Extraction from SystemC Designs Using Debug Symbols and the SystemC API Jannis Stoppe∗ Robert Wille∗y Rolf Drechsler∗y ∗Institute of Computer Science, University of Bremen, 28359 Bremen, Germany yCyber-Physical Systems, DFKI GmbH, 28359 Bremen, Germany fstoppe,rwille,[email protected] Abstract—Due to the ever increasing complexity of hardware SystemC API are applied for this purpose. Both, static and and hardware/software co-designs, developers strive for higher dynamic information is thereby retrieved. levels of abstractions in the early stages of the design flow. Using the proposed approach, restrictions and limitations of To address these demands, design at the Electronic System Level (ESL) has been introduced. SystemC currently is the “de- the previously introduced solutions are avoided. The proposed facto standard” for ESL design. The extraction of data from approach considers the established criteria for SystemC design system designs written in SystemC is thereby crucial e.g. for the extraction [19]: proper understanding of a given system. However, no satisfactory • As few as possible a priori limitations are assumed, support of reflection/introspection of SystemC has been provided • precise information on all parts of a given system are yet. Previously proposed methods for this purpose either focus on static aspects only, restrict the language means of SystemC, provided, or rely on modifications of the compiler and/or parser. • code reuse is maximized in order to avoid creating a In this work, we present an approach that overcomes these new C++ dialect and to ensure that the solution is also limitations. A methodology is introduced which enables full applicable to future SystemC compilers, and extraction of the desired information from a given SystemC • high level TLM constructs are supported. design without changing the SystemC library or the compiler. For this purpose, debug symbols generated by the compiler and A comparison to previously introduced approaches confirms SystemC API calls are exploited. The proposed system retrieves the benefits of our approach. Particularly with respect to a both, static and dynamic information. A comparison to previously priori limitations and code reuse, our approach clearly satisfies proposed solutions shows the benefits of the proposed method, the desired criteria. The precision ultimately depends on the while its application is illustrated by means of a visualization engine. amount of details provided in the debug symbols. However, the I. INTRODUCTION amount of data that can be gathered is more than sufficient for The complexity of the design of hardware and software tasks like system understanding. The respective pros and cons systems, especially in the hardware/software co-design, is ever of the proposed approach are discussed in more detail later in increasing. To counter this development, engineers strive for Section VI-A. Furthermore, the applicability of the proposed higher levels of abstractions which, eventually, led to the de- approach is demonstrated by means of a visualization engine. sign of such systems at the Electronic System Level (ESL) [16]. The remainder of this work is structured as follows: In For this approach, SystemC [21] currently is the “de-facto order to keep the paper self-contained, the next section briefly standard” [15], [22]. reviews the basics on SystemC and introduces a running However, due to SystemC being a C++ library, it lacks the example to be used in this work. Section III reviews and native support for reflection and introspection other system discusses previously introduced solutions and, therefore, forms description languages (like Esys.net [4], [12], [13] or HJJ [10]) the motivation of this work. Afterwards, Section IV introduces provide. Consequently, extracting meta information from a the general idea of the proposed approach while Section V pro- given system description is a crucial task as (1) the source code vides details on its implementation. Results of the evaluation, is hard to parse due to the complex structure and the variety i.e. the comparison to previous work as well as the application of dialects of C++ and (2) the compiled binaries are basically of the extracted results in a visualization engine, are reported stripped of all the information that is not needed for execution, in Section VI. Finally, the paper is concluded in Section VII. but might be required for reflection and introspection. II. SYSTEMC Current approaches try to address these problems by pro- SystemC is a C++ library for modeling and simulating viding solutions which system designs. By providing descriptions means for both, • focus on static aspects only [2], [3], [6], [7], [11] or hardware concepts (like modules, signals, ports, etc.) and soft- • execute the design using custom(ized) parsers, compilers, ware concepts (like class instantiations, function calls, memory and/or SystemC libraries that only support a restricted allocation, etc.), it allows to model and to execute hardware sub-set of SystemC [8], [9], [19]. and software systems on various levels of abstraction. While This results in limitations concerning the SystemC constructs modules (representing parts of a hardware system) and their being used. connections are instantiated, the logic behind those can be In this work, we introduce a methodology for information both, made up of simulated hardware elements down to gate extraction of SystemC designs which addresses these prob- level or just a software simulation of the behavior that is lems. The general idea is to exert available data and interfaces supposed to be realized in hardware later on. SystemC is as much as possible in order to avoid any restrictions and considered an “industry standard” [22] and is widely used to dependencies. More precisely, debugging symbols generated prototype hardware/software systems and co-systems as well by an off-the-shelf compiler in combination with the existing as their behavior. 1 # i n c l u d e <systemc.h> 2 SC_MODULE( f u l l A d d e r ) { 3 sc_in <bool > a, b, carryIn; 4 sc_out <bool > result , carryOut; 5 void calculate() { (a) Standard SystemC flow 6 carryOut.write((a && carryIn) || (b && carryIn) || (a && b)); 7 result.write((a && !b && !carryIn) || (!a && b && !carryIn) || 8 (!a && !b && carryIn) || (a && b && c a r r y I n ) ) ; 9 } 10 SC_CTOR(fullAdder): a("a"), b("b"), result("result" ), carryOut("carryOut") { 11 SC_METHOD( c a l c u l a t e ) ; 12 sensitive << a << b; 13 } (b) Extracting information using previously proposed solutions 14 }; 15 i n t sc_main ( i n t a r g c , char ∗ argv [ ] ) { 16 i n t b i t s = 2 ; 17 i f ( a r g c > 1) 18 bits = max(0, min(16, atoi(argv[1]))); 19 f u l l A d d e r ∗ p r e v i o u s ; 20 f o r ( i n t i = 0; i < bits; i++) { 21 f u l l A d d e r ∗ f a = new fullAdder("fullAdder"); 22 i f ( i > 0) { 23 s c _ s i g n a l <bool >∗ s i g = new s c _ s i g n a l <bool >("carrySignal"); 24 p r e v i o u s −>c a r r y I n (∗ s i g ) ; (c) Solution proposed in this work 25 fa −>c a r r y O u t (∗ s i g ) ; 26 } Fig. 2. Extracting information from SystemC designs 27 previous = fa; 28 } 29 return 0 ; variables, etc. often can hardly be extracted [15]. Particularly, 30 } if the program depends on user input (e.g. the parameter Fig. 1. SystemC program specifying the bit-width in the carry-ripple adder from Fig. 1), Example 1. Fig. 1 shows a SystemC program which is used as this information cannot be grasped from the static code at all. running example in the remainder of this paper. The program Hybrid approaches usually cover these drawbacks by ad- realizes a simple carry-ripple adder. The bit-width of the adder ditionally taking into account run-time information. Most is not statically defined, but will be provided by the user existing approaches rely on customized, i.e. non-standardized, when executing the program. This is realized by iteratively tools. As an example, Pinapa [15], [19] uses a “slightly instantiating new one-bit full adders. modified version of SystemC” and requires “a patch to the III. MOTIVATION GNU C++ compiler” [20]. The approach presented in [8] SystemC enables to implement and simulate complex hard- uses a PCCTS based parser, which effectively restricts the ware/software systems. Fig. 2a briefly shows the correspond- descriptions means of SystemC. Hence, current hybrid ap- ing flow which is basically identical to the typical software proaches do not fully support the entire instruction set of design flow: The desired system is implemented in SystemC C++. Moreover, these approaches are written specifically for and compiled by an off-the-shelve compiler. Finally, the re- the existing sub-set of SystemC – in order to support future sulting binary can be executed to simulate the system. releases of SystemC, they need to be re-developed. However, to be able to further process a SystemC design Overall, existing approaches either suffer from beyond its mere simulation, information concerning the struc- • being focused on static aspects only, ture of the design needs to be extracted. Due to the lack • need a customized adaption of SystemC and, therefore, of native support for reflection and introspection, researchers are not applicable e.g. to future releases of SystemC, or developed several approaches concerning the extraction of • rely on customized compilers/parsers which limit the information from a given SystemC design. Basically, they can applicable language constructs. be categorized as follows [15]: • Static Approaches extract information by interpreting This is also briefly summarized in Fig.