As the plugin is not only written for GCC, but other compilers simply do not offer this architecture, it is not portable and relies heavily on the project being interoperable with the chosen architecture. This even excludes projects that rely on workflows based on older versions of the GCC, with the plugin API being a rather recent addition to the project. Another approach that uses a debugger is presented in [ 19 ].
Although the focus of this approach is on the actual debugging of the system, it still handles the same issues to inspect the system in the first place i. Like SHaBE, this approach uses GDBto extract the data from the running program and therefore suffers the same lock-in issues as the former. While this tool comes with its own visualization to control the debugging environment, it uses a proprietary engine by Concept Engineering to do so, thus limiting the availability of the system.
Hybrid approaches split the analysis into two parts. First, the static information is extracted from or by the compiler, which is translating the program anyway. Second, the executable file generated by the compiler is executed, and the dynamic information esp.
SystemC object instances is extracted from the running program. While the approach differs slightly for these implementations, they share the same features of a dynamic extraction. Basically, the idea that a compiler has access to all structures and can be used to modify the output in any way holds. A design that is handled using either of these tools can be analyzed well: AST and both static and dynamic structures are extracted, so the output of these methods is thorough.
However, this information retrieval approach does still come with a trade-off. Both solutions are tightly intertwined with the compiler that they are based on GCC, in both cases ; either because the compiler itself is modified as in Pinapa [ 14 ] or because a plugin specific to that compiler needs to be used during compilation as in SHaBE [ 18 ]. This implies that no other setup may be used in order for the respective implementation to be applied.
The impact of this fact differs depending on the code base. As the build process differs from compiler to compiler, setting up the build environment for a new compiler is usually a cumbersome, but still manageable task.
Different environments have access to different libraries and tools. The problem of dialects even exists within the same environment: updating a compiler may break the compilation for some source constructs.
Shop with confidence
This is a problem for this approach, as the number of available compilers is currently limited, with closed-source compilers probably remaining unsupported, due to the missing ability to add features at will. The solution to rewrite a potentially large code base to get data extraction support is a time-consuming and, therefore, expensive task that should be avoided if possible.
The hybrid approach therefore comes with the most promising, yet also quite limiting notion of either supporting a given SystemC project and being able to export the full design down to the abstract syntax tree or not supporting it at all. Based on this limitation, we have suggested another approach that sticks to the hybrid approach of separately extracting static and dynamic data from a system, but sets the focus on compatibility in order to support a wider variety of build setups.
LENSE [ 22 ] extracts dynamic and static information without touching a workflow's internals, such as the compiler or the SystemC kernel. As compilers need to provide the debugger with the information needed to give a detailed view of the program's state in memory while it is running, they write most of this information to disk during compilation. Macros, preprocessor directives, includes, etc. Furthermore, as the debug symbols or the respective interfaces work as an interface between the compiler and the debugger, their structure is unlikely to change often.
Combined with the point that all major compilers have accessible symbols, this renders this approach more robust and universally applicable than the modification of one specific compiler. To get the dynamic information e. When using the debug information at run-time, the extracted dynamic instances even exceed the SystemC objects that can be retrieved via the SystemC API. As the debug symbols contain the memory layout of a given class and the objects can be mapped to their classes , references to non-SystemC objects can be resolved at run-time, resulting in a full snapshot of all objects that are referenced by SystemC objects directly or indirectly.
Compared to other hybrid approaches, the data can be retrieved practically without further prerequisites from any given setup.
However, the static data of this approach are limited to the information present in the debug symbols, which usually does not include the full abstract syntax tree. This missing information means that this approach, while being more easily applicable, is best suited for, e.
Tasks, like, e. All hybrid methods share one important core feature: the system's elaboration phase is executed, allowing the extraction tool to extract the dynamically generated instances of, e. This clearly sets them apart from the static parsing approaches, which rely on being able to statically determine the system's design from its source code, which poses all sorts of problems, including user-generated input, like files, to be read by or parameters to be passed to the program.
An ordinary execution of at least the elaboration phase and the successive combination with the static data gathered from, e. Concerning the example from Figure 1 , the design can be analyzed using hybrid approaches by executing the constructor of the top module and simply monitoring or later extracting all created modules.
If the given example contained any platform-specific source code, the major question left would be if the code base is supported by the given tool. However, this approach does not come without certain downsides. First and foremost, the environment used to extract the information needs to support the given code base. Second, in the case of LENSE, the user has to pay for the compatibility that the information does not contain, e.
Especially, Pinapa and SHaBE are tied to their compilers and, hence, are restricted to the input language, which may not match the dialect used in the program to be analyzed.
Another method that is based on modifying the source code in a separate preprocessing step before compilation might promise more platform-interoperability while giving more precision than LENSE. The hybrid approaches outlined in Section 4 rely on modifying the system's dynamic behavior. These modifications are applied during or after compilation. However, a program's behavior might also be modified before compilation by altering the source code instead. While refactoring a program manually is a tedious, time-consuming task, aspect-oriented programming AOP is a paradigm that allows the designer to write refactoring rules that are applied before compiling a program a process called weaving.
Basically, these refactoring rules are separated into elements describing the functionality that is supposed to be inserted into the source code and the definition of locations where these changes are supposed to occur. This scheme therefore allows a designer to describe new functionality almost independent of the existing implementation. Figure 5 illustrates how the aspect weaver takes the newly described functionality and inserts it into the existing source code at the defined locations, thereby adding to or replacing functionality that previously existed in the so-called component code with the one described in the additional aspect code.
Aspect-oriented programming allows the designer to combine the original SystemC source code with aspect code.
Download Quality Driven Systemc Design
A preprocessor the aspect weaver combines these into new source code, which is compiled as usual. The aspect code can be used to, e. The process is fully automatic and can be compared to a preprocessor that modifies the source code before compilation. The major problem with rewriting code to add new functionality the approach being time consuming and, therefore, expensive does not apply to this approach, as the refactoring rules are applied automatically. Furthermore, adding it to the compilation workflow of course results in another tool being used that requires the given code base to be compatible.
This approach obviously offers a non-intrusive way to extract information about a running SystemC design, but not just that. As inserting monitor elements that do not alter the way a system works, but merely track what happens while, e. Feature localization is a way of determining the location of a certain functionality in a design by comparing traces of different runs.
Each run is marked to either contain or not contain a certain feature. After executing all runs, the differences in the traces of all runs are used to determine likely locations of each feature. In [ 27 ], we implemented a feature localization method that uses AOP to embed a gcov-based tracer that traces the executed lines of code into the source code of a given SystemC project in a way that also the object instances such as modules in a design that execute a given line are recorded.
The resulting feature localization is able to locate features not only in the source code, but is also able to pinpoint object instances that are responsible for triggering these features.
- The Ruined Map: A Novel?
- Quality-Driven Systemc Design: By Daniel Groae, Rolf Drechsler | eBay.
- Essentials of Neuroimaging for Clinical Practice.
AOP, in this case, provides a framework to embed this sophisticated monitor into existing SystemC projects. CHIMP adds another layer of abstraction above the usual writing of AOP advice code, taking instead properties and locations in a custom language and generating the according aspect code. While this does not allow matching syntax on a semantic basis which might be a problem for statements that should be matched, but contain some unexpected character , it is a solution that should work fine for most cases.
Although not combined in a single tool, [ 29 ] outlines the application of AOP for metrics collection, functional verification, communication and the more specific use cases of a cache replacement policy and the separation of control and data streams for given examples. Usually, the resulting source code that is generated during the weaving process is quite complex. This is not only a problem for its readability and debugging, but also for the synthesization of hardware from a given SystemC design if the original design was composed from SystemC's synthesizable subset and meant to be translated into hardware.
Although the focus on hardware development and synthesizability seems fitting, ASystemC relies on a custom parser for the interpretation of the original SystemC code, sacrificing portability in order to implement its own engine. As SystemC designs usually focus on a system's structure and behavior especially in their early stages of development , concerns, such as power estimation, are usually ignored at first and hard to add later on.
AOP provides an easy way to add the needed code for power estimation throughout a design, adding the code that implements the corresponding power model once the structural and functional description is done without the need for any heavy refactoring [ 31 ]. The diversity of implemented approaches shows that AOP is well suited to handle many cases in the development of SystemC designs.
There are several advantages to the AOP approach: Aspects can be toggled at will before compilation, resulting in binaries that do not contain code that is not needed. Therefore, there is no performance impact of unused aspects, making them a suitable choice even for expensive operations, as long as rebuilding the project frequently is an option.
Quality-Driven SystemC Design - Semantic Scholar
Furthermore, aspects can be combined. Unlike, e. Practically, as refactoring rules usually rely on naming conventions, there might be conflicts or unwanted side-effects when combining several aspects if, e. Generally, adding a preprocessing step before the compiler's preprocessor is a valid and working approach that solves many problems, but does not come without its penalties. For example, debugging AOP setups becomes a more complex task.
Errors in the aspect code may be inserted into the original code base several hundred times or more, resulting in huge error listings. Although [ 28 ] added the ability to match any regular expression which does not necessarily always correspond to a single syntactic or semantic meaning , it is ultimately limited to whatever is available in the source code. Implementing, e. Generally, AOP provides an elegant way to alter a given design's source code at compile time to insert missing functionality without excessive manual work.