such as Verilog, SystemVerilog, SpecC, VHDL and SystemC. [3], [2], [12], [1] that ... designs, assertion-based design verification, and testbench generation ...
1
CARH*: A Service Oriented Architecture for Validating System Level Designs Hiren D. Patel, Deepak A. Matthaikutty, David Berner, Sandeep K. Shukla,
Abstract— Existing system level design languages and frameworks mainly provide a modeling and a simulation framework. However, there is an increasing demand for supporting tools to aid designers in quick and faster design space and architectural exploration. As a result, numerous tools such as integrated development environments and others that help in debugging, visualization, validation and verification are commonly employed by designers. As with most tools, they are targeted for a specific purpose, making it difficult for designers to possess all desired features from one particular tool. Only public-domain tools can be easily extended or interfaced with other existing tools, which a lot of the existing commercial tools do not promote. Having an extendable framework allows designers to implement their own desirable features and incorporate them into their framework. However, for technology reuse and transfer, it is important to have a tidy infrastructure for interfacing the extension with the framework, such that the added solution is not highly coupled with the environment making distribution and deployment to other frameworks difficult if not impossible. This requires a plugand-play framework where features can be easily integrated. In this paper, we tackle these issues of extendibility, deployment, the inadequacies in system level design languages and frameworks by presenting a service oriented architecture for validating system level designs for SystemC called CARH, that uses a variety of open-source technologies such as Doxygen, Apache’s Xerces XML parsers, SystemC, TAO and ACE. Index Terms— SystemC, CORBA, Middleware, Reflection, Introspection, Verification and Validation, Embedded System Design
I. I NTRODUCTION The rising complexity of embedded system design and the increasing engineering efforts for their realization has resulted in a widening of the productivity gap. Efforts towards mitigating the productivity gap have raised the importance of System Level Design (SLD)s languages and frameworks. In recent years, we have seen SLD languages such as SystemC, SpecC, SystemVerilog [1], [2], [3] in efforts to raise the level of abstraction in hardware design. These SLDs assist designers in modeling, simulation and validation of complex designs. However, the overbearing complexity and heterogeneity of designs make it difficult for embedded system designers to meet the time-to-market with just the provided SLDs. Hence the proliferation of numerous commercial tools supporting SLD languages with features for improved model building experience. This shows that designers need improved techniques, methodologies and tools for better debugging, visualization, validation and verification in order to improve productivity. * We code name our software systems after famous computer scientists. CARH (k¨ ar) stands for C. A. R. Hoare.
Most of the present SLD languages and frameworks (SLDL) are primarily equipped with a modeling and simulation environment and lack facilities to ease model building, visualization, execution analysis, automated test generation, improved debugging, etc., which are becoming increasingly important to enhance the overall design process. As evidenced by the release of commercial tools such as Debussy [4], ConvergenSC [5], VCS [6], Incisive [7] to mention a few, SLDL themselves require additional supporting tools. However, with the multitude of commercial tools, a designer must select the set of tools that best fits his/her needs and many times the existing tools do not suffice. This raises an issue of extendibility, where designers have no way to extend the commercial tools or solutions to suit their own specific needs. Even if the SLDL can be subject to alterations, the abundance of open-source tools are subdued by the issue of efficient deployment mechanisms and reusability. In addition to the ability of designers to extend a framework, they should also be able to cleanly interface and distribute their solution for integration with other SLDLs. Some industrial outcomes to addressing these inadequacies in SLDLs are simulation-based dynamic validation frameworks such as ConvergenSC [5], VCS [6] and Cadence Incisive [7]. However each of these tackle various aspects of the design process. There are some overlapping features and some distinct desirable features, and at this moment it is not possible to unify the capabilities into one framework. Furthermore, the inherent problem of extendibility, disallows users to consider altering or integrating these different frameworks. In efforts to address these issues with industrial simulationbased dynamic validation frameworks and the lack of features for SLDLs, we propose a simulation based dynamic validation framework called CARH as a solution for SystemC. CARH is a service oriented verification and validation framework using middleware technology. In particular we employ TAO [8] that is real-time (R/T) CORBA Object Request Broker (ORB) [9] and ACE [10], to allow for a language independent pluggable interface with the framework. We show the use of public domain tools, Doxygen, XML and Xerces-C++ for structural reflection of SystemC models, thus avoiding using front-end parsing tools such as EDG [11]. We exploit the opensource nature of SystemC to perform runtime reflection. We also introduce services for improved debugging, automated test generation, coverage monitoring, logging and a reflection service. ACE also provides design pattern implementations for multi-threaded models, thread pooling and synchronization. The inherent R/T facilities from TAO allows for R/T software modeling. This is also ideal for cosimulation, because it fa-
2
cilitates independent languages that support CORBA to easily interface with CARH. In CARH we have built a R/T middleware based infrastructure using Event service and Naming service among CORBA services, and by building a number of domain specific facilities such as reflection, automated test generation and dynamic-value change dump (d-VCD). A. Main Contributions We enlist the fundamental contributions of our work: Service-orientation a necessary approach for allowing a multitude of features that enable multi-platform debugging, visualization, performance and coverage monitoring for system level designs. • The use of a standardized interface-based mechanism for allowing the different services to communicate and exchange information amongst themselves. Using the OMG standardization of CORBA-variant implementations, any new feature that follows this standardization can be easily integrated into CARH. • Introspective facilities for the models: Facilitating any such capabilities requires that the infrastructure have the ability to introspect the models. Our reflection and introspection mechanism improves debugging capability by providing automated test generation and extraction of runtime information of SystemC models. • Debugging facilities: Unfortunately, standard debuggers prove less useful when debugging multi-threaded models and we need to facilitate the designer with model execution information in terms of call graphs, dynamic-Value Change Dump (d-VCD) and logging facilities. • Automated test generation capabilities: Even though SCV has utilities for randomized constraint and unconstrained based test generation, there is no infrastructure that automatically generates testbenchs for particular models and stimulates them.
•
B. Organization In Section 2, we briefly discuss the inadequacies of SLDLs and current dynamic validation frameworks. The following section outlines our approach to addressing these inadequacies. In Section 4, we discuss related work with Reflection and Introspection (R-I) along with the technologies we employ in endowing SystemC with R-I. Section 5 presents the CARH architecture followed by a detailed description of the services rendered. Section 7, describes the usage model for the CARH framework. In Section 8, we provide simulation result for the FIR and FFT modeled using CARH framework and finally concluding remarks and future work in Section 9. II. I SSUES AND I NADEQUACIES OF C URRENT SLDL S DYNAMIC VALIDATION FRAMEWORKS
AND
There are numerous SLDLs employed in the industry such as Verilog, SystemVerilog, SpecC, VHDL and SystemC [3], [2], [12], [1] that primarily comprise of two aspects. The first being a modeling framework and the other being a simulation framework. The modeling framework allows
designers to express designs either in a programmatic or graphical manner and the simulation framework is responsible for correctly simulating the expressed model. Designers can create models using the modeling framework and verify the design via simulation. However, with the rising complexity in current designs, it is not enough to simply provide designers with a modeling and simulation framework. It is becoming evident that designers require supporting tools to increase their productivity and reduce their design time. We enlist some of the important supporting features that are necessary for today’s designers. They are: introspection in SLD languages and frameworks, automated testbench generation, coverage monitors, performance analysis and enhanced visualizations. There are several industrial solutions that are targeting problem areas in SLDLs by providing some of these above mentioned features. However, instead of describing the multitude of commercial solutions for some of the inadequacies with SLDLs, we discuss some of the validation frameworks that are commercially available for improving design experience. Some of them consist of the features that we realize as being important for SLDLs. Few of the popular validation framework solutions are ConvergenSC [5], VCS [6] and Cadence Incisive [7]. Each one of these tools have good solutions for different aspects in aiding designers for improved validation and model building experience. For example, ConvergenSC presents a SystemC integrated development environment (IDE) using Eclipse. This IDE has project management support, version control and build support. It also has an advanced debugging environment allowing step-wise execution that is specially geared towards QuickThreads used in SystemC. Although ConvergenSC provides a good IDE for improving design productivity and debugging, it does not support any testbench generation features that are crucial for correctness of designs. On the other hand, VCS targets the aspect of RTL verification by incorporating multi-language support for Verilog, VHDL, SystemVerilog and SystemC, coverage techniques for Verilog and mixed-HDL designs, assertion-based design verification, and testbench generation constructs. It can interface with other Synopsys products. Similarly, Incisive from Cadence also supports some of the similar features for integrated transaction environment, unified simulation and debug environment, assertion support and testbench generation. By simply looking at some of these commercial solutions, we notice that neither one of these tools fully suffice the needs of a designer. One apparent and a major drawback in the above mentioned industrial solutions is that of extendibility. Due to the commercial nature of these tools, it is impossible for designers to extend the existing framework themselves. Even though ConvergenSC’s Eclipse IDE allows for plugins, their debugging facilities may not be easily extendable as desired by users. Furthermore, none of these solutions are open-source, disallowing users to consider alterations. Hence, designers have to look elsewhere for technology that can complement their existing solution. None of these tools can satisfy every designer’s requirements thus necessitating the use of a variety of additional tools. For example, a designer may require ConvergenSC as an IDE, but also has to use VCS for RTL
3
verification along with System Studio for system level design support. Even then, the use of multiple commercial tools may still not satisfy a specific purpose in the mind of the designer. This difficulty can be overcome by providing a framework that is a part of the public-domain, and that is easily extendable. Another important concern is the deployment and reuse of technology. Often times, there are designers who create specific tools to perform certain tasks that are difficult to distribute because the tools are highly coupled with their environment. For example, suppose some designer implements a hot-spot analyzer for ConvergenSC as a plugin. This plugin would probably be highly coupled with the Eclipse and ConvergenSC environment making it difficult to adapt to other IDEs or environments. Therefore, another designer using a different environment may have difficulty in interfacing with this plugin without using that particular set of tools. Hence, it is important that extendibility is followed by a clean deployment mechanism so that plugins interact with their environment through an interface such that an easy adaptation to a different third party environment is possible. A well constructed solution for deployment also promotes unification of relevant tools with a clean interfacing mechanism that facilitates seamless interoperability between multiple tools. III. O UR G ENERIC A PPROACH TO A DDRESSING I NADEQUACIES
THESE
We propose a generic approach that addresses the primary inadequacies of extendibility, deployment and reuse in existing validation frameworks and features for supporting tools that we perceive as being important for SLD languages and frameworks. A. Service Orientation Our approach promotes the idea of service orientation in SLDLs, where features are implemented as services that interact with each other through IDL interfaces that are language neutral interfaces defined by OMG [13]. Thus, the entire architecture comprises of multiple floating services that can be queried by clients through a common interface. Furthermore, this solution must be part of the public-domain such that designers may add services at their will. Extendability comes naturally with such an approach because a particular feature can simply be integrated into the architecture as a service that can also employ other existing services. In addition, deployment is relatively easy because the newly added service follows a strict interface convention that it must adhere. Lastly, the implementation of the feature can be independent of the interface as a service, allowing easy distribution and reuse of the feature. Furthermore, features from different language paradigms may be integrated with the architecture as long as the language can interact with the interface mechanism. This means multi-language services can be integrated into the architecture through this service/interface mechanism. For example, a visual interface displaying performance graphs and tables may use Java as the core language. However, the actual simulation is performed in a C++ based environment and the interface
mechanism allows for the two to communicate and exchange messages. The advantage of following the OMG standardization, which TAO or any other CORBA-variant adheres to, is that all implementations of OMG standards can be seamlessly used with CARH. A commercial tool that can conform to such a standard allows for easy integration and adoption to CARH. In addition, these features can be distributed over multiple computers or networks promoting a distributed simulation and validation infrastructure. An example of using a distributed framework is described in [14], that allows compilation and execution of testbenches on a distributed network. B. Introspection Architecture The use of introspection is commonly seen in programming languages such as Java and languages that use the .NET framework. However, infiltrating introspective capabilities in SLDLs is still a sought after feature. Most attempts at introspection in SLDLs are facilitated via structural reflection, but runtime reflection also offers even more possibilities. If an SLDL inherits introspective capabilities, then projects such as IDEs, value-change dump (VCD) viewers, improved debugging, and call graphs could take advantage of the reflected information. Unfortunately, there are very few nonintrusive methods for structural reflection and hardly any for runtime reflection [15]. C. Test Generation and Coverage Monitor Most designers are also responsible for constructing their testbenches that perform sanity and functional tests on their designs. Manual testbench generation is tedious and many times randomized testbenches, weighted testbenches, range-based testbenches are sufficient in validating functional correctness. Furthermore, a testbench generator can take advantage of an introspective architecture to query information regarding ports, signals, types, bitwidths, etc. and then automatically with some user-hints generate testbenches. However, most SLDLs do not come with a facility to automatically generate testbenches. Thus, making it another important supporting feature for SLDLs. Coverage monitors provide a measure of the completeness of a set of tests. Computing coverage during validation requires runtime information. This is where the runtime reflection capability can be exploited. In this paper we do not discuss about specific algorithms for test generation or coverage driven test generation because this paper is about the service oriented validation framework and these are but a few examples of services we need to integrate in such an environment. So the interfaces of these services are relevant to this paper and not the algorithms themselves. D. Performance Analysis As with most large designs, simulation efficiency is usually a major concern for designers for timely validation purposes. For this, performance analysis features are essential to SLDLs. There are designers who require hot-spot analysis to identify the bottlenecks of the design such that they can focus their
4
optimization techniques towards that section. There are numerous metrics for measuring the time consuming blocks. For hardware design languages using a discrete-event simulation, we envision a performance analysis service that provides the designer with the following capabilities: • The amount of time every hardware block or module consumes. • The time spent in computation per module versus intermodule communication time. • The number of times a particular block is scheduled to execute. • The frequency of delta events and timed events generated by modules. • Designer specified timers for identifying time taken in particular sections of the implementation. • Version comparisons such that altered versions of the design can be aligned with the previous versions and performance metrics can be easily compared through graphs and tables. These are some of the many capabilities that we see important for performance comparisons. However, performance analysis features are crucial in SLDLs for improving simulation efficiency of the designs, thus an important required feature for SLDLs.
Visualization in an SLDL toolkit can use data available from other services such as the coverage monitors, introspection architecture, and performance analysis and aid the designer in better comprehending this data. The more services an SLDL offers the more possibilities are there. Visualization can help to take design decisions based on more information in less time. The authors of [17] report an approach for interfacing visualization GUIs to SystemC. However, with the reflection capabilities in CARH we can provide a similar interface in an easier manner. Until now we discussed the role of SLDLs in modeling and simulation, the need for supporting tools for SLDLs and a good infrastructure for deployment, extendibility and reuse. Now, we present CARH, a service oriented framework for validation of SystemC models. The SLDLs we choose for our experimentation is SystemC [1] and employ the TAO [8] and ACE [10] libraries for the service orientation and implement additional services to promote the supporting features.
E. Visualization
A. Reflection and Introspection
When working with large designs, a visual representation can be helpful in many ways. Visualization is an important tool for the designer to keep an overview and better manage the design. Using a graphical representation than requiring designers to traverse through many lines of code can immensely benefit design experience. Especially during architectural exploration and refinement, visualizations can help to take important decisions or to reveal problematic areas of the design. Visualizations for communication hotspots, code usage, or online control flow analysis can give fast intuitive information about important key figures of the design. In order to obtain meaningful and visually appealing graphs, we need two things: (i) The required data has to be collected and be made easily available. This can be rather obvious for static information such as the netlist or the module hierarchy, but may require important infrastructure support for dynamic information such as communication load or code coverage. (ii) The data has to be processed into visual graphs. This can be a very complex task depending on the type of graph and the level of desired flexibility and interaction. However there are many existing libraries and toolkits that can be used to render a graph structure. The Debussy nSchema and nWave modules [4] for example, are commercial tools for waveform and structural layout visualization. The GraphViz package [16] is an example for a comprehensive graph visualization package that can render and display different types of graphs such as simple textual description and others. Since SLD languages do not come with tools providing such visualizations, we see an important need to add this infrastructure to SLD toolkits in order to take advantage of advanced SLD features.
Introspection is the ability of an executable system to query internal descriptions of itself through some reflective mechanism. The reflection mechanism exposes the structural and runtime characteristics of the system and stores it in a data structure. We call data stored in this data structure metadata. This data structure is used to query the requested internal characteristics. The two sub-categories of the reflection metadata are structural and runtime. Structural reflection refers to descriptions of the structure of a system. For SystemC, structural reflection implies module name, port types and names, signal types and names, bitwidths, netlist and hierarchy information. On the other hand runtime reflection exposes dynamic information such as the number of invocations of a particular process, the number of events generated for a particular module and so on. An infrastructure that provides for R-I (either structural or runtime reflection) is what we term an reflection service.
IV. BACKGROUND & R ELATED W ORK In this section we define reflection and introspection followed by descriptions of some frameworks and languages that provide R-I along with the open-source tools that we employ in deriving our solution for R-I and CARH.
B. Existing tools for structural reflection Several tools may be used for implementing structural reflection in SystemC. Some of these are SystemPerl [18], EDG [11], or C++ as in the BALBOA framework [19] and Pinapa [20]. However, each of these approaches have their own drawbacks. For instance, SystemPerl requires the user to add certain hints into the source file and although it yields all SystemC structural information, it does not handle all C++ constructs. EDG is a commercial front-end parser that parses C/C++ into a data structure, which can then be used to interpret SystemC constructs. However, interpretation of SystemC constructs is a complex and time consuming task,
5
plus EDG is not available in the public domain. BALBOA implements its own reflection mechanism in C++ which again only handles a small subset of the SystemC language. Pinapa is a new front-end for SystemC that offers an intrusive solution for parsing SystemC by altering GCC and SystemC’s source code. As for runtime reflection, to our knowledge, there is no framework that exposes runtime characteristics of SystemC models. C. ESys.NET Framework and Introspection in SystemC ESys.NET [21] is a system level modeling and simulation environment using the .NET framework and C# language. This allows ESys.NET to leverage the threading model, unified type system and garbage collection along with interoperability with web services and XML or CIL representations. They propose the managed nature of C# as an easier memory management solution with a simpler programming paradigm than languages such as C or C++ and use the inherent introspective capabilities in the .NET framework for quicker debugging. They also employ the common intermediate language (CIL) as a possible standard intermediate format for model representation. One of the major disadvantages of using the .NET framework is that it is platform dependent. The .NET framework is primarily a Microsoft solution and making it difficult for many industries to adopt technology built using the .NET architecture because of well-established Unix/Unix-variant industrial technologies. There are obvious advantages in making ESys.NET a complete mixed-language modeling framework interoperable with SLDLs such as SystemC. However, we see no easy solution for interoperability between managed and unmanaged frameworks partly because integrating the unmanaged project in a managed project reduces the capabilities of the .NET architecture. For example, mixing managed and unmanaged projects does not allow the use of .NET’s introspection capabilities for the unmanaged sections of the project. A natural way to interact between different language paradigms and development approaches (managed versus unmanaged) is to interface through a service oriented architecture. Microsoft has their own proprietary solution for this such as COM, DCOM and .NET’s framework. Unfortunately, one of the major drawback as mentioned earlier is that C# and .NET framework is proprietary technology of Microsoft. Even though there are open-source attempts at imitating C#, the .NET framework as a whole may be difficult to conceive in the near future [22]. The authors of [21], inspired by the .NET framework’s reflection mechanism propose the idea of a composite design pattern for unification of datatypes for SystemC. They enhance SystemC’s datatype library by implementing the design pattern with additional C++ classes. This altered datatype library introduces member functions that provide introspection capabilities for the particular datatypes. However, this requires altering the datatype library and altering the original source code to extract structural information. This raises issues with maintainability with version changes, updates and standard changes due to the highly coupled solution for introspection. A different approach for exposing information about SystemC models to graphical user interfaces (GUI) is described
in [17]. This work describes a methodology for interfacing SystemC with external third party tools where they focus on a GUI value-change dump viewer as the external tool. This requires allowing the VCD viewer to probe into the SystemC model and display the timestamp, the type of the signal and the current value of the signal. The authors document the required changes to the SystemC scheduler sc simcontext, sc signal and sc signal base classes along with their additional interface classes to expose the type of a SystemC signal and its corresponding value. They implement the observer pattern such that the VCD viewer accepts the messages from the altered SystemC source and correctly displays the output. D. BALBOA Framework The BALBOA [19] framework describes a framework for component composition, but in order to accomplish that, they require R-I capability of their components. They also discuss some introspection mechanisms and whether it is better to implement R-I at a meta-layer or within the language itself. We limit our discussion to only the approach used to provide R-I in BALBOA. BALBOA uses their BIDL (BALBOA interface description language) to describe components, very similar to CORBA IDLs [9]. Originally IDLs provide the system with type information, but BALBOA extends this further by providing structural information about the component such as ports, port sizes, number of processes, etc. This information is stored at a meta-layer (a data structure representing the reflected characteristics). BALBOA forces system designers to enter metadata through BIDL, which is inconvenient. Our method only needs pre-processing of SystemC models. Another limitation of this framework is that the BIDL had to be implemented. Furthermore, the designer writes the BIDL for specifying the reflected structure information which can be retrieved automatically from SystemC source. BALBOA also does not perform runtime reflection. E. Java, C# .NET Framework, C++ RTTI Here, we discuss some existing languages and frameworks that use the R-I capabilities. They are Java, C# and the .NET framework and C++ RTTI. Java’s reflection package java.lang.reflect and .NET’s reflection library System.Reflection are excellent examples of existing RI concept implementations. Both of these supply the programmer with similar features such as the type of an object, member functions and data members of the class. They also follow a similar technique in providing R-I, so we take the C# language with .NET framework as an example and discuss in brief their approach. C#’s compiler stores class characteristics such as attributes during compilation as meta-data. A data structure reads the meta-data information and allows queries through the System.Reflection library. In this R-I infrastructure, the compiler performs the reflection and the data structure provides mechanisms for introspection. C++’s runtime type identification (RTTI) is a mechanism for retrieving object types during execution of the program.
6
Some of the RTTI facilities could be used to implement R-I, but RTTI in general is limited in that it is difficult to extract all necessary structural SystemC information by simply using RTTI. Furthermore, RTTI requires adding RTTI-specific code within either the model, or the SystemC source and RTTI is known to significantly degrade performance. F. Doxygen, XML, Apache’s Xerces-C++ Two main technologies we employ in our solution for RI for SystemC are Doxygen and XML. Doxygen [23] is a documentation system primarily for C/C++, but has extensions for other languages. Since SystemC is simply a library of C++ classes, it is ideal to use Doxygen’s parsing of C/C++ structures and constructs to generate XML representations of the model. In essence Doxygen does most of the difficult work in tagging constructs and also documenting the source code in a well-formed XML representation. Using XML parsers from Apache’s Xerces-C++ we parse the Doxygen XML output files and obtain any information about the original C++/SystemC source. G. TAO and ACE TAO [8] is a real-time CORBA implementation using the ACE [10] environment. ACE is a library of C++ classes that implement design patterns with focus on network application programming. TAO and ACE together facilitate the user with CORBA and design pattern capabilities. H. Service Oriented Software Many distributed applications use middleware such as CORBA [9] to integrate a system with services and floating objects accessible via ORB. System level design languages can take advantage of middleware for cosimulation purposes as shown in [24]. [25] discusses a cosimulation environment for SystemC and NS-2 [26] which can also be integrated into CARH with relative ease. In addition effective testing and parallel simulation execution is viable as demonstrated by [14]. CARH utilizes the TAO & ACE environments to provide a service oriented architecture extendable for cosimulation, distributed testing and any user-desired services. V. CARH’ S S OFTWARE A RCHITECTURE The architectural description in Figure 1 serves as an extendable road map for CARH. The services and the SystemC models (SystemC-V) are the two main separations in Figure 1. The distinguishing arrows show interaction between the services and the SystemC model. The primary interaction is using an ORB to access services other than the d-VCD that happens to use TCP/IP protocols for communication. First we briefly describe the services within CARH: Reflection: This consists of two sub-services, where the first exposes structural information about the model and similarly the second exposes runtime/behavioral information about the model. Testbench: This service automatically generates SCV-based testbenches for the SystemC model using the introspection
capabilities provided by CARH. Coverage: This performs coverage analysis on collected runtime information and results from simulation to regenerate better testbenches. Logger: It allows logging of runtime information based on logging requests entered through the user console. d-VCD: The d-VCD service is independent of an ORB and communicates through network communication protocols. The test generation, coverage monitor and logger services require the reflection and CORBA services. These services can be configured and invoked by a user console. It provides a dynamic-Value Change Dump on the reflected module along with the processes on the SystemC runlist. The services below are employed by CARH but implemented in CORBA: Naming: Allows a name to be associated with an object that can also be queried by other services to resolve that name and return the associated object. Event: Allows decoupled communication between the requestors/clients and the services via an event based mechanism. A clean method to implement push and pull interactions between clients and services. The remainder elements and facilities of the architecture shown in Figure 1 are described below: SystemC-V: We implement SystemC-V that supports the SystemC Verification library (SCV) [1] and it also contains an extended version of SystemC 2.0.1 that communicates on an ORB and presents runtime information for introspective clients/services. The ORB: The OMG CORBA [9] standard distinguishes between horizontal CORBA services, and vertical CORBA facilities. According to that terminology, only CORBA horizontal services we use from TAO are Event and Naming services. On the other hand the reflection, logger, test generation and coverage monitoring services are implemented by us, and qualify as domain specific vertical services. Console: CARH is operated via the client. The client is a text-based interface that has commands to perform tasks for the user such as startup services, set specific service related flags, specify models to execute and so on. One of the main strengths of CARH is the possibility of extensions. Developers can write TAO-based services and easily interact with the existing architecture via the interfaces defined. This opens up the possibility of an architecture that can be extended to support what is described in [24] and [14] along with many other pluggable services. Those services can easily be integrated in this architecture. Moreover ACE allows the use of design patterns [27] that can be effectively used to implement multi-threaded models and design-specific servers. For example, our implementation of d-VCD uses the Acceptor-Connector design pattern from the ACE library. The multiple models shown being executed on SystemC-V are a consequence of leveraging the ACE threading mechanisms to simulate concurrent models. The Usage model in Section VII steps through showing how CARH is used. Obviously, there
7
Fig. 1.
CARH Software Architecture
is a simulation performance price to pay for using such an infrastructure. Our early experiments show them in tolerable ranges as reported in Section VIII. VI. S ERVICES
RENDERED BY
CARH
The ability to introspect structural characteristics of a model promotes a large variety of services, of which we currently implement the automated testbench generator and logger services. However, with emphasis on improving methodologies for debugging and model building experience, we extract runtime characteristics from the model as well and describe the d-VCD service. These two services made possible by the introspective architecture are not to be thought of as the only possible services, but simply two of the many that may follow. In addition, with the inherent facility of CORBA with the inclusion of TAO, we provide an elegant infrastructure for a distributed test environment. In this section, we describe these services in effort to prescribe examples which can employ the R-I and TAO capabilities. A. Reflection Service Doxygen, XML & Structural reflection: Processing C++/SystemC code through Doxygen to yield its XML documentation is ideal for data reflection purposes. The immediate advantages are that Doxygen output inserts XML tags where it recognizes constructs specific to the language such as C++ classes and it also preserves the source code line by line. The first advantage makes it easy to target particular class objects for further extraction and the latter allows for a well-defined medium for extracting any information from the source that may not be specific to an implementation. Since all SystemC constructs are not recognized during this pre-processing, we use the well-formed XML format of the source code as input to an XML parser to extract further structural information. We leverage this well-formed XML-based Doxygen output to extract all necessary SystemC constructs not tagged by Doxygen itself using the Xerces parser and we implemented an additional C++ library to generate an Abstract System
Level Description (ASLD). ASLD is written in a well-formed XML format that completely describes each module with the following information: signal and port names, signal and port types and bitwidths, embedded SystemC processes and their entry functions, sensitivity list parameters, and its hierarchy. We introduce a DTD specific for SystemC constructs that validates the ASLD for correctness of the extraction. The reflection service reads the ASLD and populates a data structure representing the model. Finally, TAO/CORBA client and server interfaces are written to make the reflection into a floating CORBA facility accessible via the interfaces. Our website [28] contains all the details and code. Given an overview of our introspective architecture, we continue to present details on the infrastructure for introspection, with SystemC being the targeted SLDL of choice. We only provide small code snippets to present our approach and the concept of using Doxygen, XML, Xerces-C++, and C++ data structure to complete the reflection service. We present details of the Doxygen pre-processing, XML parsers employed in extracting uninterpreted information from SystemC source files, our method of storing the reflected meta-data and our data structure allowing for introspection. SystemC DTD
SystemC Model
Doxygen
XML Parser
ASLD Generation
Phase 1
Fig. 2.
Data Structure
Phase 2
Design Flow for Reflection Service
Doxygen pre-processing: Using Doxygen has the benefit of simplifying C/C++ parsing and its corresponding XML representations. However, Doxygen requires declaration of all classes for them to be recognized. Since all SystemC constructs are either, global functions, classes, or macros, it is necessary to direct Doxygen to their declarations. For example, when Doxygen executes on just the SystemC model
8
then declarations such as sc in are not tagged, since it has no knowledge of the class sc in. The immediate alternative is to process the entire SystemC source along with the model, but this is very inconvenient when only interested in reflecting characteristics of the SystemC model. However, Doxygen does not perform complete C/C++ compilation and grammar check and thus, it can potentially document incorrect C/C++ programs. We leverage this by adding the class definition in a file that is included during pre-processing and thus indicating the classes that need to be tagged. There are only a limited number of classes that are of interest and they can easily be declared so Doxygen recognizes them. As an example we describe how we enable Doxygen to tag the sc in, sc out, sc int and sc uint declarations. We include this description file every time we perform our pre-processing such that Doxygen recognizes the declared ports and datatypes as classes. A segment of the file is shown in Figure 3, which shows declaration for input and output ports along with SystemC integer and SystemC unsigned integer datatypes. /*! SystemC port classes !*/ template class sc_in { }; template class sc_out { }; /*! SystemC datatype classes !*/ template class sc_int { }; template class sc_uint { };
Fig. 3.
Examples of class declarations
The resulting XML for one code line is shown in Figure 4. Doxygen itself also has some limitations though; it cannot completely tag all the constructs of SystemC without explicitly altering the source code, which we avoid doing. For example, the SC MODULE(arg) macro defines a class specified by the argument arg. Since we do not include all SystemC files in the processing, Doxygen does not recognize this macro when we want it to recognize it as a class declaration for class arg. However, Doxygen allows for macro expansions during pre-processing. Hence, we insert a pre-processor macro as: SC MODULE(arg)=class arg: public sc module that allows Doxygen to recognize arg as a class derived from class sc module. We define the preprocessor macro expansions in the Doxygen configuration file where the user indicates which files describe the SystemC model, where the XML output should be saved, what macros need to be run, etc. We provide a configuration file with the pre-processor macros defined such that the user only has to point to the directory with the SystemC model. More information regarding the Doxygen configuration is available at [23]. Even through macro pre-processing and class declarations, some SystemC constructs are not recognized without the original SystemC source code. However, the well-formed XML output allows us to use XML parsers to extract the untagged information. We employ Xerces-C++ XML parsers to parse the Doxygen XML output, but we do not present the source code here as it is simply a programming exercise, and point the readers at [29] for the source code. XML Parsers: Using Doxygen and an XML parser we
SYSTEMC MODULE SC_MODULE(fir) { sc_in reset; sc_in input_valid; sc_in sample; sc_out output_data_ready; sc_out result; sc_in CLK; SC_CTOR(fir) { SC_CTHREAD(entry,CLK.pos()); } void entry(); };
sc_in sc_in fir::reset reset
sc_out sc_out fir::result result
DOXYGEN OUTPUT
