Several other tools manipulate SystemC programs. Some present themselves as SystemC front-ends, but none of them meet our requirements.
SystemPerl is a perl library containing, among other tools, a netlist extractor for SystemC (a netlist is a description of the connections between modules). It uses a simple grammar-based parser and will therefore not be able to deal with complex code in the constructors of the program, and does not extract any information from the body of the processes.
Synopsys developed a SystemC front-end that has successfully been included in products like CoCentric SystemC Compiler and
CoCentric System Studio. It parses the constructors and the main function, as well as the body of the modules with the
EDG C++ front-end, and infers the structure of the program from the syntax tree of the constructors.
Semantic Designs uses a SystemC Parser/Front End in some of their tools. Unfortunately, the tool is not available for download or for evaluation. To the best of our knowledge, the approach they use has not been published.
SystemCXML seems to use the same approach, using
doxygen's C++ front-end. Using this technique, to be able to parse any SystemC program, one must be able to compute the state of any program at the end of the execution of the constructors knowing their bodies. In other words, the tool must contain a re-implementation of a C++ interpreter.
The University of Bremen recently developed a SystemC front-end called
ParSyC. The approach is similar to the one of Synopsys, except that the grammar is written from scratch (including both SystemC and C++ constructs) instead of reusing an existing C++ front-end.
sc2v (The site is down as of april 2009, see also here) is also a SystemC synthesizer, built with the same approach. It is written using lex and yacc tools, and targets only an RTL subset of the language (which is reasonable if the goal is synthesis, but helpless for TLM models).
In the paper Parsing SystemC: an Open-Source, Easy to Extend Parser, the author present another front-end, tailored for the Behavioral Synthesizable SystemC subset (BSSC), also based on a grammar. The tool is based on a C grammar, slightly extended to manage the most basic constructs of C++. They would require a huge amount of work to manage the full C++ language correctly. The paper presents the tool as being open-source, but doesn't give its name nor a download URL.
KaSCPar (Karlsruhe SystemC Parser) is also based on a grammar, and is written in Java (with JavaCC). It is available free of charge, although part of it (sc2xml) is not open-source.
To be complete, this approach needs to include all the C++ syntax (to parse the program) and semantics (to interpret the constructors).
The team of Daniel Kroening in ETH-Zurich developped several tools manipulating SystemC code, described among other in
Race Analysis for SystemC using Model Checking. They use a home-make C++ front-end extended to deal with SystemC. It is not publicly available as of now.
Quiny, presented in
The Quiny SystemC Front End: Self-Synthesising Designs at FDL06, uses a clever approach to parse SystemC code: it relies on C++ overloading of operators (and may need manual redefinition of C++ keywords) to let the body of processes build the abstract syntax tree at runtime. For example, without redefinition, executing
will compute the sum
y + z, and assign it to
x. With appropriate overloading of + and =, it will build the abstract syntax tree for the expression and the assignment.
While the approach of Quiny is clever and elegant, it also has a lot of limitations (inability to redefine some C++ operators such as ? :, need to redefine keywords manually, ...) which make it inappropriate for a real, fully automatic tool.
Some lint tools such as
AccurateC also manipulate SystemC code. AccurateC can check rules both in the code (this is an extension of a C++ lint tool) and in the netlist. However, it does not need the link between the behavior and the netlist (unfortunately, the internal structure of AccurateC has not been published at time of writing).
Some simulation tools provide an alternative to the reference simulator, with additional features like VHDL or Verilog cosimulation. For simulation, these tools do not need information about the body of the processes in uncompiled form, so, their requirements are different from ours. One particular case is
NC-SystemC: it also provides source-level debugging, using the EDG C++ front-end. The approach is therefore similar to ours, since the tool has to deal with both syntax and architecture information. However, this tool is focused on debugging, and is anyway not available to the public.
