A

Parsing SystemC using C/C++ Front-endCompiler

This chapter1 presents a more involved, but robust approach for parsing Sys-temC for structural and behavioral information using the Edison C/C++Front-end Group compiler (EDG) [28]. This is a commercial product thatallows parsing C/C++ source code and we use it for parsing SystemC. Wedocument our infrastrucure in non-intrusively adding our parser (from hereforth it will be called walker) with EDG and then detail on how we extractcertain information from the source. Our walkers should work with version ofEDG that are higher than version 3.8 given that certain crucial properties oftheir internal data structures have not changed. We also use Autotools [131]to simplify the deployment of our parser, called FEDG.

SystemCSource

EDG Library FEDG Library Xerces Library

EDGIL TREE Walkers XML

DOM

Fig. A.1. Parsing Flow Using EDG

A.1 Tool Flow

The parsing of SystemC source begins by specifying the SystemC source filesas input to the tool (Figure A.1). The source files are then run throughEDG’s C/C++ front-end compiler that creates an intermediate language (IL)

1 Derek O’Neill is a co-author of this chapter.

188 A Parsing SystemC using C/C++ Front-end Compiler

representation; a complex data structure in the form of a tree, that containsthe C/C++ equivalent information about the source files. Since our needs re-quire parsing SystemC constructs, we take the EDG IL tree as input to a setof walkers that consist of functions to traverse the EDG IL tree and populatesecondary data structures. Our library, FEDG Library contains these walkersthat are used to extract SystemC constructs. The secondary representationuses the Xerces Library to create an XML document object manager (DOM)that only stores the information relevant to SystemC.

A.2 Parsing SystemC

EDG’s IL representation of C++ consists of several basic building blocks.Each source file, function definition, and class declaration is represented asa scope. Sections of source code that are grouped together by braces aregenerally represented as a scope object. Contained in a scope object is likelyto be a block of statements. This ‘block’ is a sequential list of each individualline of code inside the scope. Each statement in this list has its own type, themost common of which is an expression (but it could also be an initialization,for example). Each expression consists of expression nodes, logically linkedtogether by operands, if the expression represents an operation. Each of thesestructures will be discussed in greater detail when they are encountered laterin this section.

Structural parsing begins with a call to the EDG function walk filescope il. This function accepts a callback function as a parameter, and willpass that callback function a pointer to each entry in the file-scope IL tree. Inthe EDG IL tree, a scope is the term for all of the code contained within a set ofbraces. This means that each function body is represented as a scope, as well asthe statements inside the braces of a while loop. There is an EDG object thatrepresents this section. There is also a special scope, the primary scope, thatis not defined by a set of braces, but rather represents the entire source. Thisscope contains all of the other scopes. The aptly named callbackFunction inmoduleparsing.cpp processes each of these entries, looking for ones that rep-resent SystemC modules. We are looking for an SC MODULE macro definition.The expansion of this macro reveals a class definition specified by the argu-ment of the macro and an inheritance relationship with the class sc module.So, next we check if the scope is of the kind that indicates a class, struct orunion declaration. We also know that a class that is an SC MODULE declarationhas a base class of sc module, so we check the list of base classes to make surewe are looking at a definition that inherits from a sc module definition. If wefind that our class scope has a base class of sc module, we begin extracting thestructure of the sc module (with a function called insertNewModule). Thisallows declarations of module classes without using the SC MODULE macro. Forexample, the parser will recognize class memory: public sc module as amodule declaration as well.

A.2 Parsing SystemC 189

Ports of the module are represented as data members of the module class.These data members in the IL tree, are contained in a linked list that is amember of the EDG structure associated with the class. By traversing thatlist and checking each element’s type for sc port, we can determine if any ofthe fields are in fact ports. We must also check the base classes of each field,though, because a port may have inherited from the class sc port, and notactually be an instance of it. We do this using the base classes list associatedwith the field. Since the data type of a port is given by a template argument(and sometimes by a type with a template argument of its own), we must getthe template arguments using a function called getTemplateArg. While we aretraversing the list of fields, we also check to see if any of the fields are derivedfrom sc module. If we find one, we know that we have encountered an instanceof a different sc module. With that instance we call addModuleInstance tofurther parse this field.

Next, we move on to identifying the processes defined by this sc module.Processes are defined in the constructor of the module either via the use ofmacros or the construction definition of the module class. We parse the sourcesuch that either methods of definition are correctly extracted. We start bytraversing the list of routines that this class declares. Once we find the routinewith the same name as the module itself (the constructor), we use the EDGfunction walk routine scope il to traverse it. We are looking for calls tocreate * process, where * is either method, thread, or cthread. Once wehave found all of these calls, we know we have a complete list of the module’sprocesses. This also handles multiple declarations of processes.

After the processes have been identified, identifySensitivity is called toparse the sensitivity expressions associated with each process declaration. TheidentifySensitivity function verifies that we are dealing with a block ofstatements and then calls the parseStatements function to check each one fora call to the sensitive function. EDG’s IL tree represents any group of state-ments, such as those inside a while loop or even those inside the same function,as a block of statements. This block contains a linked list of statement ob-jects, each one representing one line of code from the original source. Since asensitivity list in SystemC is effectively a call to the sensitive function, it willbe represented as one statement. Traversing a block of statements allows us toidentify that sensitivity statement for parsing. Function parseStatements willrecursively call itself when it finds a nested statement block, and it will callparseExprForSensitivity when it finds an expression identified by EDG.The function parseExprForSensitivity attempts to traverse the expressiontree of a valid sensitivity expression of a SystemC process (which is expressedin the constructor). The operands pointer in an expression node points to alist of one or more operands that make up the expression. Some operationshave two or more operands (such as the addends in an addition operation),while others may have only one (such as the variable to be negated by theunary negation operator). When parsing operations, it is usually necessaryto traverse the expression tree using these operands pointers. The SystemC

190 A Parsing SystemC using C/C++ Front-end Compiler

implementation overloads the << operator to specify the signals that are to bemade sensitive. This amounts to identifying a function call for operator<< inthe IL tree. If a function call is found in the expression, and the routine beingcalled is operator<<, it calls the function scan sensitivity expression.This function traverses the expression tree in all of the ways that would bevalid for different sensitivity expressions.

When defining a hierarchical module, instances of other modules and theirconnections are specified in the constructor. To identify these connectionsbetween modules that are declared in this constructor, thefindConnectionsInRoutine function is invoked. This function iterates overthe statement list of the constructor, checking each statement for the sequenceof expression nodes that occurs with each different type of connection(sc clock, sc signal, sc in, sc export, etc.). Since there is a differentsequence of next and operands pointers to follow for each different signaltype in a connection, this routine must check each one to find out whichtype of connection it has encountered. A separate case must also be consid-ered for port-to-port binding (when a signal is connected using the syntax:(in(gate->out)), since there is yet another different sequence for thisscenario.

All of the previous parsing was done inside the sc module definition. Therest of the structural parsing described here is done inside the sc main func-tion. It includes no new methods of parsing, but instead it is just different waysof obtaining information about instances and connections that are declaredin sc main.

Instances can be declared in two ways: an object instance of the mod-ule and a dynamically created module instance. These instances in sc mainare identified by the function identifyInstances. The first task this func-tion does is to find the sc main routine. The function iterates over everyroutine in the file scope until it finds the routine called sc main. Then, theidentifyModuleInstances function looks at every statement in sc main forone that is an initialization. If it is an instance of an sc module, it will be adynamic initialization expression or a constructor.

Connectionsinsc mainareidentifiedbythefunctionidentifyConnections.This function again identifies the sc main routine by iterating through the list ofroutines in the top-level object from which all IL objects can be accessed. Onceit finds that scope it passes it to the findConnectionsInRoutine function,which operates exactly as it did before (when it was searching the constructorof an sc module) to find the connections. If a function called from withinthe constructor contains connection information, that information is currentlynot parsed. To incorporate this functionality, the findConnectionsInRoutinemethod could be recursively passed the pointer to any functions called withinthe constructor.

Behavioral parsing begins in much the same way as structural pars-ing does, with a call to walk file scope il with a callback function. Thewritefinder callback function again looks for sc module definitions and calls

A.2 Parsing SystemC 191

parseStatementsForWrite to identify the constructs we are looking for. TheparseStatementsForWrite function checks for many common behavioral con-structs that will be required to parse behavioral information from the module.It currently checks for if statements, loops, switch statements, and returnstatements. When it encounters one of these elements, it adds the appropri-ate elements to the XML document object manager (DOM) and recursivelyparses the statements inside the element. The parseExpression function isused to build a string representation of the main expression of the statement(the test condition for an if statement, for example). Since there are over 150different possible expression types, the parseExpression function currentlyonly works for a subset of expressions, such as equality operations, inequalityoperations, and function calls.

Along with checking for these behavioral constructs, the expressions of theloops and if statements are checked for calls to wait, write on ports andsignals, and read on ports and signals by the function traverseAnExpr. Ituses EDG’s built-in traverse expr function, which operates likewalk file scope il in that it is passed a callback function and it returns apointer to each expression node in the tree to that function. In our callbackfunction we examine each node in the expression and look for a routine call toeither write, read, or wait. At this time, any function called write or readwill be identified by this method. To be more correct, however, the algorithmshould verify that the call is made on an sc signal object (or a derivitive ofsc signal in out if). This would prevent a false positive identification of auser-defined function of the same name. Once a read or write call is foundon any object, the function follows the correct sequence of operands and nextpointers to get the port name and the variable that is being accessed.

An XML DOM is used to store all the behavioral and structural infor-mation in an XML format built on top of [123]. The format of our DOMfollows the .dtd file included with the distribution. An example of initializa-tion of the DOM can be seen in the function initXMLDocument function inBack End.cpp. The DOM is printed to a file using the justserialize func-tion in structuraltoxml.cpp, adapted from the print example in the Xercesdistribution. TheDOMDocument->createElement(X(“name”)) call is used to create a new ele-ment in the XML document. The attributes of that element can be set usingthe DOMElement->setAttribute(X(“name”), X(“value”)) call. Children ofthe element can be created as new independent elements and can be appendedto the parent with the DOMElement->appendChild(element) call. After be-ing run on an input file, the program will output the DOM to a file calledxmloutput.xml in the root of the program’s installation.

B

Eclpise-based Plugin for a SystemC IDE

B.1 Project Overview

Requirements: Eclipse 3.2.x [126]; CDT 3.1.x [124]; a C++ compilerPlatforms: Any platform that Eclipse and CDT support.Installation: 1. Use the Eclipse Update Manager to use the following URL

as the Remote Sitehttp://fermat.ece.vt.edu/tools/systemcide/scide site/.

2. Download the zip file, and extract the folders into the Eclipse root.

The SystemC IDE [127] project1 is organized into an Eclipse plug-in andfeature. The feature governs all of the plug-ins that are related to the Sys-temC IDE. At this point, there is only one plug-in for the project, but in thefuture, as the project grows, it may be reasonable to split the project into mul-tiple plug-ins. The feature also allows the project to be distributed throughthe Eclipse Updates Manager. Having a familiarity with Eclipse plug-in andfeature projects will definitely provide an advantage for future modifications.

B.2 SystemC IDE Feature

The only file of concern in this feature is feature.xml. Eclipse will auto-generate a lot of the details of the feature through wizard inputs. Openingthis file in Eclipse will open it in the Feature Editor. Under the Plug-ins tab,edu.vt.fermat.scide has been added as a project that it governs. If Eclipse hasnot done it, dependencies must be calculated by going to the Dependenciestab and clicking the Compute button. Dependencies are the other plug-ins(for this project, some are Eclipse-provided, others are CDT).

1 Nick Sandonato is a co-author of this chapter.

194 B Eclpise-based Plugin for a SystemC IDE

Fig. B.1. Project Workspace and Hierarchies

B.3 SystemC IDE Plug-in

The governing file for a plug-in is plugin.xml. Much like the feature, depen-dencies are defined in the Dependencies tab. These are not automaticallycalculated like with the feature project. Additionally, it is possible to viewthe XML source code for the plug-in by clicking on the plugin.xml tab. Inthis file, the SystemC IDE project extends other plug-ins to provide the en-vironment’s functionality. Explaining everything in this file would be outsideof the scope of an overview. Understanding it would require some reading ofEclipse plug-in development, and also understanding some of the CDT projectextension points [126, 124] (Figure B.1).

B.3.1 Plug-in Source

The plug-in project has been broken up into multiple packages. Each packagehas a fairly self-explanatory naming convention. Classes of notable interest:

SystemCEditor – Responsible for presenting a SystemC source editor (at thistime, focusing on SystemC-specific syntax highlighting)

SystemCCodeScanner – Responsible for adding SystemC keywords to the ed-itor’s parsing rules and add specific coloring to these words

SystemCPreferencePage – Responsible for providing user-stored preferencesfor the SystemC development environment

NewManagedSystemCProjectWizard – Responsible for creating a managedSystemC project (i.e., the Makefile is generated for the user). Additionally,this class is responsible for making sure the include and library paths fora SystemC project are set up properly

B.4 Setting up the SystemC IDE 195

At the moment, SystemC macros and types are colored the same as C++keywords. In the future, it is definitely possible to define a new page in System-CPreferencePage to regulate macro and type colors. This would also requiredrawing a difference between macros and types in SystemCKeywordSets.

B.4 Setting up the SystemC IDE

This assumes that one has already installed Eclipse 3.2, CDT 3.1, and SCIDE1.0. Starting up Eclipse for the first time will present the user with an envi-ronment as in Figure B.2.

Fig. B.2. Default Eclipse Environment

B.4.1 Setup the SystemC Preferences

The user must specify where the SystemC include and library paths are. Toaccomplish this, modify the SystemC Preferences (Figure B.3) by going to:Window > Preferences... > SystemC.

B.4.2 Creating a Managed SystemC Project

The easiest way to manage a SystemC project is to allow the environmentto manage the Makefile and building of the project. To create a managedSystemC Project: File > New > Project > Managed Make SystemC Project.

196 B Eclpise-based Plugin for a SystemC IDE

Fig. B.3. SystemC Preferences

Supply a project name then select Finish. The workspace will confirm a per-spective change to the SystemC Perspective. Accept this perspective change,and there will be a new project in the workspace (Figure B.4).

Fig. B.4. A New SystemC Project in the Workspace

B.5 A Little About Implementation 197

B.4.3 Adding Files to the Project

There are various ways to add source (or any other) files to a SystemC Project.It is possible to use the SystemC wizards to create source files, the unique wiz-ard is the Module Creation Wizard. This wizard will automatically generatea header file that contains a module definition. Alternatively, source files maybe imported from other projects through Eclipse’s Import Wizard. The Im-port Wizard can be accessed by right clicking on the project and selectingImport? Navigate to the source files, and Finish the import process. Either ofthese methods will trigger the CDT’s automatic build process.

B.4.4 Executing a SystemC Project

To execute a SystemC project, the previous steps must be completed. If thereare no errors with the project (Figure B.5), the project can be run.

Fig. B.5. The Eclipse Problems View Reporting a Warning

Select Run > Run.... Select C/C++ Local Application, and then click theNew icon.

Next, specify the project and Search the project for the project’s exe-cutable (Figure B.6).

Finally, select Run to execute the program. The Console View (Figure B.7)will display the output of the program-if any.

B.5 A Little About Implementation

The SystemC Integrated Development Environment (SCIDE) is truly an ex-ample of the extensibility and reusability of the Eclipse and CDT environ-ments. In particular, SystemC’s relationship with the C++ proves to be veryadvantageous in minimizing development time and code duplication.

B.5.1 The Plug-In File

The file plugin.xml plays an important role in Eclipse projects. It is at theheart of how the project will extend the Eclipse environment. The variousextensions tell the Eclipse environment how to make use of the classes devel-oped in the following sections. A full-out discussion of the file is outside of thescope of this paper, as there are many excellent resources available; however,there are no portions of this that stand out in anyway.

198 B Eclpise-based Plugin for a SystemC IDE

Fig. B.6. Selecting an Executable to Run

Fig. B.7. Console View of a Completed SystemC Project

B.5.2 The Editor

A majority of the SystemC Editor’s functionality-like content assist-is takencare of by the CDT’s CEditor class. To incorporate the SystemC language’skeywords into the editor for syntax highlighting purposes was made easiersince the language is a superset of C++. The SCKeywords class, while addingSystemC’s keywords, extends the CDT’s Keywords class to provide the key-words of C++.

The SystemCEditor class initializes the editor by setting the source viewerconfiguration, which is a class that sets up a code scanner for the SystemClanguage. The code scanner, SystemCCodeScanner, utilizes the keywords de-fined by SCKeywords to create a rule set for how text should be highlighted.There are various Rule-type classes, to which individual rules, or words, are

B.5 A Little About Implementation 199

added. These rules are all collectively added to a generic list of rules thatthe createRules method of the SystemCCodeScanner returns. The SystemCEditor is now capable of applying these rules to provide syntax highlighting.

B.5.3 The Preference Page

The SystemCPreferencePage is currently the primary preference page forSystemC Projects. This class extends the traditional Eclipse preference page,and allows developers to set the SystemC library, compiler options, and in-clude file locations. Currently, these preferences must be defined before aSystemC Project is created in order for the project to be aware of these spec-ified preferences. The Preference Page utilizes what is known as a PreferenceStore, which is defined by the SystemCPlugin class. The Preference Storewill maintain the SystemC preferences that have been saved for the currentworkspace. Changing workspaces, however, will result in a different set ofSystemC preferences.

The actual control is built in the method createContents where labels,text areas, buttons, and listeners are initialized. Each button requires a listenerthat defines what happens; generally, a dialog is opened for this preferencepage. Additionally, there are a few buttons that are built into the page auto-matically: Restore Defaults, Apply, Cancel, and OK. There are overrideablemethods (performDefaults and performOk) that handle the correspondingactions. It is worthwhile to note that the Apply button will actually invokethe method performOk. The method performOk will take the values in thetext areas of the control, and save them to the Preference Store that is de-fined for this workspace. The method performDefaults will set the text areasof the control to contain the default values defined by the SystemC plug-in.Currently, the preferences are very environment-specific, so they are emptystrings by default.

B.5.4 The Wizards

The SystemC IDE has numerous wizards to aid in development. Most of thewizards are fairly self-explanatory, ranging from creating an entire SystemCproject down to the specific source files that make up the project. A ma-jority of the wizards take advantage of the extensibility of the CDT plugin,modifying window titles and images associated with the wizard.

The NewManagedSystemCProjectWizard is the workhorse of the SystemCIDE. This class sets up a SystemC Project that, through underlying capabili-ties of the CDT, maintains the Makefile needed to build the project. Because ofthis automation, and SystemC’s dependency on external libraries, it was nec-essary for the wizard to add some additional configurations. The preferencesthat are saved in the SystemC Preference Store are added to the configura-tion for the underlying CDT project through the overridden doRun method.

200 B Eclpise-based Plugin for a SystemC IDE

The method manipulates the build information of the new project using theCDT’s ManagedBuildManager.

The NewModuleCreationWizard is a SystemC-specific wizard. Muchlike the CDT has a Class Creation Wizard, SystemC has a Module Cre-ation Wizard. At its current stage, the wizard will generate a header filecontaining a new SystemC Module with some of the basic elements of amodule. The NewModuleCodeGenerator class, which extends the CDT’sNewClassCodeGenerator class, is responsible for generating the file andadding the template code.

References

1. Network Simulator 2. Network Simulator 2. http://www.isi.edu/nsnam/ns/.2. A. Amar, P. Boulet, J. Dekeyser, S Meftali, S. Niar, M. Samyn, and J. Vennin.

SoC Simulation. http://www.inria.fr/rapportsactivite/RA2003/dart2003/.3. F. Baader and T. Nipkow. Term Rewriting and All That. Cambridge University

Press, 1998.4. Brian Bailey, Grant Martin, and Andrew Piziali. ESL Design and Verification.

Morgan Kaufmann, 2007.5. M. Barnett, W. Grieskamp, L. Nachmanson, W. Schulte, N. Tillmann, and

M. Veanes. Towards a Tool Environment for Model-based Testing with AsmL.Petrenko and Ulrich, editors, Formal Approaches to Software Testing, FATES,2931:264–280, 2003.

6. M. Barnett, K. R. M. Leino, and W. Schulte. The Spec# programming sys-tem: An Overview. Construction And Analysis of Safe, Secure, And Interoper-able Smart Devices: International Workshop, CASSIS 2004, Marseille, France,March 10-14, 2004: Revised Selected Papers, 2005.

7. M. Barnett and W. Schulte. The ABCs of Specification: AsmL, Behavior, andComponents. Informatica, 25(4):517–526, 2001.

8. R. A. Bergamaschi. The Development of a High-Level Synthesis System forConcurrent VLSI Systems. Ph.D. thesis, University of Southampton, 1989.

9. D. Berner, D. A. Mathaikutty, H. D. Patel, and S. K. Shukla. AutomatedExtraction of Structural Information from SystemC-based IP for Validation.In Proceedings of Microprocessor Test and Verification, pages 99–104, 2005.

10. D. Berner, H. D. Patel, D. A. Mathaikutty, S. K. Shukla, and J.P. Talpin.SystemCXML: An Extensible SystemC Front End Using XML. In Proceedingsof Forum on Design and Specification Languages, 2005.

11. G. Berry. The Constructive Semantics of Pure Esterel. Draft book, availableat http://esterel.org, version 3, 1999.

12. S. Bhattacharyya, P. Murthy, and E. A. Lee. Software Synthesis from DataflowGraphs. Kluwer Academic, 1996.

13. Bluespec. Bluespec. http://bluespec.com/.14. Boost. Boost graph library. http://www.boost.org.15. E. Borger and R. Stark. Abstract State Machines: A Method for High-Level

System Design and Analysis. Springer, 2003.

202 References

16. Borland. Borland VisiBroker: A Robust CORBA Environment for DistributedProcessing. http://www.borland.com/us/products/visibroker/index.html.

17. J. Bresenham. Bresenham’s Line Drawing Algorithm. http://www.cs.helsinki.fi/group/goa/mallinnus/lines/bresenh.html.

18. F. Bruschi, F. Ferrandi, and D. Sciuto. A Framework for the Functional Ver-ification of SystemC Models. International Journal of Parallel Programming,33(6): 667–695, 2005.

19. Cadence. Incisive Functional Verification. http://www.cadence.com.20. C. Campbell, W. Grieskamp, L. Nachmanson, W. Schulte, N. Tillman, and

M. Veanes. Model-Based Testing of Object-Oriented Reactive Systems withSpec Explorer. Technical Report MSR-TR-2005-59, Microsoft Research, 2005.

21. Celoxica. Celoxica’s Agility Compiler. http://www.celoxica.com/products/agility/.

22. L. Charset, M. Reid, E. M. Aboulhamid, and G. Bois. A Methodology forInterfacing open source SystemC with a Thirdparty Software. In Proceedingsof Design and Test Automation in Europe, pages 16–20, 2001.

23. CoWare. ConvergenSC. http://www.coware.com.24. N. Dave, M. C. Ng, and Arvind. Automatic Synthesis of Cache-Coherence

Protocol Processors Using Bluespec. In Proceedings of Formal Methods andModels for Codesign, pages 25–34, July 2005.

25. F. Doucet, S. K. Shukla, and R. Gupta. Introspection in System-Level Lan-guage Frameworks: Meta-level vs. Integrated. In Proceedings of Design andTest Automation in Europe, pages 382–387, 2003.

26. Doxygen. Doxygen. http://www.stack.nl/ dimitri/doxygen/.27. E. A. de Kock, G. Essink, W. J. M. Smits, P. van der Wolf, J. -Y. Brunel,

W. M. Kruijtzer, P. Lieverse, and K. A. Vissers. YAPI: Application Modelingfor Signal Processing Systems. In In the proceedings of Design AutomationConference, pages 402–405, 2000.

28. Edison Design Group C++ Front-End. Edison Group Front-End. http://edg.com/cpp.html.

29. S. A. Edwards. Making Cyclic Circuits Acyclic. In Proceedings of DesignAutomation Conference, pages 159–162, 2003.

30. Esterel-Technologies. Lustre. http://www-verimag.imag.fr/ synchron/.31. FERMAT. SystemC-H. http://fermat.ece.vt.edu/systemc-h/.32. L. Formaggio, F. Fummi, and G. Pravadelli. A Timing-Accurate HW/SW

Co-simulation of an ISS with SystemC. In Proceedings of the 2nd IEEE/ACM/IFIP international conference on Hardware/software codesign and sys-tem synthesis, pages 152–157, 2004.

33. Forschungszentrum Informatik. KaSCPar - Karlsruhe SystemC Parser Suite.http://www.fzi.de/sim/kascpar.html.

34. FORTE. Forte Design Systems. http://www.forteds.com/.35. E. Gamma, R. Helm, Johnson R, and J. Vlissides. Design Patterns. Addison

Wesley, 1995.36. E. R. Gansner and S. C. North. An open graph visualization system and its

applications to software engineering. Softw. Pract. Exper., 30(11):1203–1233,2000.

37. A. Gawanmeh, A. Habibi, and S. Tahar. Enabling SystemC Verification us-ing Abstract State Machines. Technical report, Department of Electrical andComputer Engineering, Concordia University, 2004.

References 203

38. F. Ghenassia. Transaction-Level Modeling with SystemC. Springer, 2005.39. A. Girault, B. Lee, and E. A. Lee. Hierarchical Finite State Machines with Mul-

tiple Concurrency Models. In Proceedings of IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, volume 18, pages 742–760,1999.

40. GreenSocs. Enabling ESL Interoperability. http://www.greensocs.com/.41. GreenSocs. Pinapa: A SystemC Frontend. http://www.greensocs.com/.42. W. Grieskamp, Y. Gurevich, W. S., and Margus Veanes. Generating Finite

State Machines from Abstract State Machines. In Proceedings of the interna-tional symposium on Software testing and analysis, pages 112–122. ACM PressNew York, 2002.

43. T. Grotker, S. Liao, G. Martin, and S. Swan. System Design with SystemC.Kluwer Academic Publishers, 2002.

44. Metropolis Group. Metropolis: Design environment for heterogeneous systems.http://embedded.eecs.berkeley.edu/metropolis/index.html.

45. Y. Gurevich. Evolving algebras 1993: Lipari Guide, pages 9–36. Oxford Uni-versity Press, 1995. In Specification and Validation Methods.

46. Y. Gurevich, B. Rossman, and W. Schulte. Semantic essence of AsmL. Theo-retical Computer Science, 343(3): 370–412, 2005.

47. A. Habibi, H. Moinudeen, and S. Tahar. Generating Finite State Machinesfrom SystemC. In Proceedings of Design, Automation and Test in Europe,pages 76–81, 2006.

48. A. Habibi and S. Tahar. Design and Verification of SystemC Transaction-Level Models. In IEEE Transactions on Very Large Scale Integration Systems,volume 14, pages 57–68, 2006.

49. Hamabe. SystemC over CORBA. http://www5a.biglobe.ne.jp/hamabe/index.html.

50. D. Harel. Statecharts: A visual formalism for complex systems. In ScientificComputing Program, volume 8, pages 231–274, 1987.

51. F. Herrera, P. Sanchez, and E. Villar. Heterogeneous System-Level Speci-fication in SystemC. In Proceedings of Forum on Design and SpecificationLanguages, 2004.

52. F. Herrera, P. Sanchez, and E. Villar. Modeling and design of CSP, KPN andSR systems in SystemC, pages 133–148. Kluwer Academic Publisher, 2004.

53. F. Herrera and E. Villar. Mixing synchronous reactive and untimed models ofcomputation in SystemC. In Proceedings of Forum of Specification and DesignLanguages, volume 5, 2005.

54. F. Herrera and E. Villar. A framework for embedded system specificationunder different models of computation in SystemC. In Proceedings of DesignAutomation Conference, pages 911–914, 2006.

55. C. Hoare. Communicating Sequential Processes. In Communications of theACM, volume 21 of 8, 1978.

56. C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.57. J. C. Hoe and Arvind. Hardware Synthesis from Term Rewriting Systems. In

Proceedings of the IFIP TC10/WG10. 5 Tenth International Conference onVery Large Scale Integration: Systems on a Chip, pages 595–619. Kluwer, BVDeventer, The Netherlands, 1999.

58. J. C. Hoe and Arvind. Synthesis of operation-centric hardware descriptions.IEEE International Conference on Computer Aided Design, pages 511–518,2000.

204 References

59. IEEE. SystemC IEEE 1666 Standard. http://standards.ieee.org/getieee/1666/index.html.

60. International Technology Roadmap for Semiconductors. International Tech-nology Roadmap for Semiconductors. http://public.itrs.net/, 2004.

61. A. Jantsch. Modeling Embedded Systems And SOC’s - Concurrency and Timein Models of Computations. Morgan Kaufmann, 2001.

62. G. Kahn and D. B. MacQueen. Coroutines and networks of parallel processes,Information Processing. In Proceedings of IFIP Congress, volume 77, pages993–998, 1977.

63. C. Kong and P. Alexander. Modeling model of computation ontologies inRosetta. In Proceedings of the Formal Specification of Computer-Based SystemsWorkshop (FSCBS), Lund, Sweden, March, 2002.

64. C. Kong and P. Alexander. The Rosetta meta-model framework. In Pro-ceedings. 10th IEEE International Conference and Workshop on the, pages133–140, 2003.

65. C. Kong, P. Alexander, and C. Menon. Defining a Formal Coalgebraic Seman-tics for The Rosetta Specification Language. In Journal of Universal ComputerScience, volume 9, pages 1322–1349. Institute for Information Processing andComputer Supported New Media, Graz University of Technology, 2003.

66. D. Kroening and N. Sharygina. Formal Verification of SystemC by AutomaticHardware/Software Partitioning. In Formal Methods and Models for Codesign,pages 101–110, 2005.

67. J. Lapalme, E. M. Aboulhamid, G. Nicolescu, L. Charest, F. R. Boyer, J. P.David, and G. Bois. .NET Framework–A Solution for the Next GenerationTools for System-Level Modeling and Simulation. volume 1. IEEE ComputerSociety, Washington, DC, 2004.

68. A. Ledeczi, M. Maroti, A. Bakay, and G. Karsai. The Generic Modeling En-vironment. Vanderbilt University, Institute for Software Integrated SystemsNashville, 2001.

69. E. A. Lee. The problem with threads. Computer, 39(5):33–42, 2006.70. E. A. Lee and D. G. Messerschmitt. Static Scheduling of Synchronous Data

Flow Programs for Digital Signal Processing. In Proceedings of IEEE Trans-actions on Computers, volume C-36 of 1, 1987.

71. E. A. Lee and A. L. Sangiovanni-Vincentelli. Comparing Models of Compu-tation. In In Proceedings of IEEE Transactions on Computer-Aided Design ofIntegrated Circuits and Systems, volume 17, pages 1217–1229. IEEE ComputerSociety, 1998.

72. M. Chiodo, P. Giusto, H. Hsieh, A. Jurecska, L. Lavagno, and A. Sangiovanni-Vincentelli. Hardware-software codesign of embedded systems. In Proceedingsof IEEE Micro, pages 26–36, 1994.

73. M. Pankert, O. Mauss, S. Ritz, and H. Meyr. Dynamic data flow and con-trol flow in high level DSP code synthesis. In Proceedings of IEEE Interna-tional Conference on Acoustics, Speech and Signal Processing, volume 2, pages449–452, 1994.

74. D. A. Mathaikutty, D. Berner, H. D. Patel, and S. K. Shukla. FERMAT’sSystemC Parser. http://systemcxml.sourceforge.net, 2004.

75. D. A. Mathaikutty, H. D. Patel, and S. K. Shukla. A Multi-MOC Frameworkfor SOC Modeling using SML. Technical Report 2004-04, Virginia Tech, 2004.

76. Mentor Graphics. Catapult C Synthesis. http://www.mentor.com/.

References 205

77. Microsoft Research. Spec#. http://research.microsoft.com/specsharp/.78. Sun Microsystems. Java. http://java.com/.79. Sun Microsystems. Java. https://javacc.dev.java.net/.80. P. Mishra, N. Dutt, N. Krishnamurthy, and M. Abadir. A Top-Down Method-

ology for Validation of Microprocessors. In IEEE Design & Test of Computers,volume 21, pages 122–131, 2004.

81. P. Mishra, N. Krishnamurthy, N. Dutt, and M. Abadir. A Property Check-ing Approach to Microprocessor Verification using Symbolic Simulation. InMicroprocessor Test and Verification (MTV), Austin, Tx, June 2002.

82. Mono. Mono Project. http://www.mono-project.com/.83. G. Moore. Cramming more Components onto Integrated Circuits. 38(8), April

1965.84. W. Mueller, J. Ruf, D. Hoffmann, J. Gerlach, T. Kropf, and W. Rosenstiehl.

The Simulation Semantics of SystemC. In Proceedings of Design, Automationand Test in Europe, pages 64–70, 2001.

85. Novas. Debussy Debug System. http://www.novas.com.86. OMG. OMG. http://www.omg.org/.87. OMG. OMG CORBA. http://www.corba.org/.88. OMG Group. Unified Modeling Language. http://www.uml.org/.89. OSCI. SystemC. http://www.systemc.org.90. H. D. Patel. HEMLOCK: HEterogeneous ModeL Of Computation Ker-

nel for SystemC. Master’s thesis, Virginia Polytechnic Institute and StateUniversity, December 2003. http://scholar.lib.vt.edu/theses/available/etd-12052003-151950/unrestricted/thesis etd2.pdf.

91. H. D. Patel, D. A. Mathaikutty, and S. K. Shukla. CARH: A Service OrientedArchitecture for Dynamic Verification of SystemC Models. In Proceedings ofIEEE Transactions on Computer Aided Design, volume 25, pages 1458–1474,2006.

92. H. D. Patel and S. K. Shukla. SystemC Kernel Extensions for HeterogeneousSystem Modeling. Kluwer Academic Publishers, 2004.

93. H. D. Patel and S. K. Shukla. Towards A Heterogeneous Simulation Kernelfor System Level Models: A SystemC Kernel for Synchronous Data Flow Mod-els. In Proceedings of International Symposium in VLSI, pages 241–242. IEEEComputer Society Press, 2004.

94. H. D. Patel and S. K. Shukla. Towards A Heterogeneous Simulation Kernel forSystem Level Models: A SystemC Kernel for Synchronous Data Flow Models.In Proceedings of ACM Great Lakes Symposium in VLSI, pages 248–253, 2004.

95. H. D. Patel and S. K. Shukla. Towards a Heterogeneous Simulation Kernel forSystem Level Models: A SystemC Kernel for Synchronous Data Flow Models.In IEEE Transactions in Computer-Aided Design, volume 24, pages 1261–1271,August 2005.

96. H. D. Patel and S. K. Shukla. Towards Behavioral Hierarchy Extensions forSystemC. In Proceedings of Forum on Design and Specification Languages,2005.

97. H. D. Patel and S. K. Shukla. Deep vs. Shallow, Kernel vs. Language - Whatis Better for Heterogeneous Modeling in SystemC? In Proceedings of Micro-processor Test and Verification, 2006.

98. H. D. Patel and S. K. Shukla. Heterogeneous Behavioral Hierarchy for SystemLevel Designs. In Proceedings of Design Automation and Test in Europe, 2006.

206 References

99. H. D. Patel and S. K. Shukla. Model-driven validation of SystemC designs.Technical Report 2006-18, FERMAT Lab. Virginia Tech., 2006.

100. H. D. Patel and S. K. Shukla. Heterogeneous Behavioral Hierarchy for SystemLevel Designs. In Proceedings of IEEE Transaction on Computer-Aided Designof Integrated Circuits and Systems, pages 565–570, 2007.

101. H. D. Patel and S. K. Shukla. Model-driven validation of SystemC designs. InProceedings of Design Automation Conference, pages 29–34, 2007.

102. H. D. Patel and S. K. Shukla. Tackling an Abstraction Gap: Co-simulatingSystemC DE with Bluespec ESL. In Proceedings of Design Automation andTest in Europe, pages 279–284, 2007.

103. H. D. Patel, S. K. Shukla, E. Mednick, and R. Nikhil. A Rule-based Model ofComputation for SystemC: Integrating SystemC and Bluespec for Co-Design.In Proceedings of Formal Methods and Models for Codesign, pages 39– 48, 2006.

104. M. Pellauer, M. Lis, D. Baltus, and R. Nikhil. Synthesis of Synchronous As-sertions with Guarded Atomic Actions. In Formal Methods and Models forCodesign, pages 15–24, 2005.

105. Ptolemy Group. Ptolemy II website. http://ptolemy.eecs.berkeley.edu/ptolemyII/.

106. M. D. Riedel and J. Bruck. The Synthesis of Cyclic Combinational Circuits.In Proceedings of Design Automation Conference, pages 163 – 168, 2003.

107. D. Rosenband and Arvind. Modular Scheduling of Guarded Atomic Actions.In Proceedings of the Design Automation Conference, pages 55–60, June 2004.

108. D. Rosenband and Arvind. Hardware synthesis from guarded atomic actionswith performance specifications. In Proceedings of International Conference onComputer Aided Design, pages 784–791, November 2005.

109. I. Sander and A. Jantsch. System Modeling and Transformational Design Re-finement in ForSyDe. In Proceedings of IEEE Transactions on Computer-AidedDesign of Integrated Circuits and Systems, volume 23, pages 17–32, January2004.

110. A. Sangiovanni-Vincentelli. Reasoning About the Trends and Challenges ofSystem Level Design. In Proceedings of IEEE, volume 95, pages 467–506,2007.

111. S. A. Sharad and S. K. Shukla. Formal Methods And Models For SystemDesign: A System Level Perspective, pages 317–331. Kluwer Academic, 2005.

112. SML-Sys Framework. SML-Sys. http://fermat.ece.vt.edu/SMLFramework,2004.

113. W. Snyder. SystemPerl. http://www.veripool.com/systemperl.html.114. SPECC. SpecC. http://www.ics.uci.edu/specc/.115. SpecExplorer. http://research.microsoft.com/specexplorer/.116. L. Stok. False loops through resource sharing. pages 345–348. IEEE Computer

Society Press Los Alamitos, CA, 1992.117. Synopsys. Smart RTL Verification. http://www.synopsys.com.118. Synopsys. Smart RTL Verification. http://www.synopsys.com.119. SystemVerilog. System Verilog. http://www.systemverilog.org/.120. Espresso Team. SIGNAL: A polychronous data-flow language. http://www.

irisa.fr/espresso/Polychrony/.121. Tensilica. XPRES Compiler. http://www.tensilica.com/products/xpres.htm.122. The ACE Group. The Adaptive Communication Environment. http://www.

cs.wustl.edu/ schmidt/ACE.html.

References 207

123. The Apache XML Project. Xerces C++ Parser. http://xml.apache.org/xerces-c/.

124. The CDT Group. Eclipse C/C++ Development Tooling - CDT. http://www.eclipse.org/cdt/.

125. The CoreASM Group. CoreASM: An Extensible ASM Execution Engine.http://www.coreasm.org/.

126. The Eclipse Foundation. Eclipse - an open development environment. http://www.eclipse.org.

127. The FERMAT Group. Formal Engineering Research with Models, Abstractionsand Transformations. http://fermat.ece.vt.edu/.

128. The TAO Group. Real-time CORBA with TAO (The ACE ORB). http://www.cs.wustl.edu/ schmidt/TAO.html.

129. S. Thompson. Haskell - The Craft of Functional Programming, 2 ed. In MA:Addison-Wesley, 1999.

130. Troll Tech. Qt. http://troll.no.131. G.V. Vaughan and T. Tromey. GNU Autoconf, Automake and Libtool. New

Riders Publishing Thousand Oaks, CA, 2000.132. VERILOG. Verilog. http://www.verilog.com/.133. VHDL. VHDL. http://www.vhdl.org/.134. XASM Group. XASM: eXtensible Abstract State Machines. http://www.

xasm.org/.135. A. S. T. Y. L. Yu, C. Hsut, and M. T. C. Lee. Eliminating False Loops Caused

by Sharing in Control Path. Proceedings of the 9th International Symposiumon System Synthesis, 1080: 96, 1820.