In the FIR example, the sensitivity list is sensitive << clk.neg();

typedef map<string, MemberExpr *> senseMapType;

The sensemap stores clk as the key and the member expr is as follows (note "neg" doesn't appear):
MemberExpr 0x50179c8 'sc_core::sc_in_clk':'class sc_core::sc_in<_Bool>' lvalue ->clk 0x50
0b0b0
`-CXXThisExpr 0x50179b0 'struct FIR

so it appears that the negation of the clock is not being captured.

For sc_in etc. of simple type e.g. sc_in, the type info associated with the declaration has two parameters, TemplateSpecializationType and BuiltinType:

number of type args is 2
TemplateSpecializationType 0x3d985a0 'sc_in<_Bool>' sugar sc_in
|-TemplateArgument type '_Bool'
`-RecordType 0x2fc96f0 'class sc_core::sc_in<_Bool>'
  `-ClassTemplateSpecialization 0x33f4e28 'sc_in'
BuiltinType 0x1ef14d0 '_Bool'

However for complex types, the second parameter is not included:

number of type args is 1
TemplateSpecializationType 0x3da0ed0 'sc_stream<find_emax::expo_t>' dependent sc_stream
`-TemplateArgument type 'find_emax::expo_t':'typename FP::expo_t'

Should complex types also resolve to a leaf class? The expo_t is defined as
typedef sc_uint expo_t;
and E is a constant via a define:
#define E 11

Since sc_stream isn't synthesizable, in the llnl examples, we are using the alternate synthesizable version defined in sc_rvd.h. When sc_rvd types are used, other classes such as sreg define sc_stream to be aliased to sc_rvd:
sreg.h:template using sc_stream_in = sc_rvd_in;
sreg.h:template using sc_stream_out = sc_rvd_out;

However, when those types are used to declare variables at the top level of an sc_module, they don't appear in any of the lists. Since they are not input or output stream ports or signals, shouldn't the appear in OtherVars? I can't find s_fp, m_fp, or m_ex declarations anywhere.

If you look at find_emax:
SC_MODULE(find_emax)
{
typedef typename FP::expo_t expo_t;

    /*-------- ports --------*/
    sc_in<bool> clk;
    sc_in<bool> reset;

    sc_stream_in <FP> s_fp;
    sc_stream_out<FP> m_fp;
    sc_stream_out<expo_t> m_ex;

    /*-------- registers --------*/
    sc_signal<sc_uint<2*DIM> > count;
    sc_signal<expo_t> emax;
    sc_signal<bool> emax_v;

    /*-------- channels --------*/
    sc_signal<bool> c_sync;
    sc_stream<FP> c_fp;
    sc_stream<expo_t> c_ex;

    /*-------- modules --------*/
    sfifo_cc<FP> u_que_fp;
    sreg<expo_t,FWD_REV> u_reg_ex;

The sc_stream declarations at the source level get redefined to sc_rvd types. In the AST dump output, those sc_rvd variables don't appear:

============== DUMP the MODULEDECL ======================
Module declaration name: find_emax

Instances:

none

Port Declaration:

Input ports: 2
Start printing ports
{
"port_arguments": {
"sc_in": [
"_Bool"
]
},
"port_name": "clk"
}{
"port_arguments": {
"sc_in": [
"_Bool"
]
},
"port_name": "reset"
}
Output ports: 0

Inout ports: 0
{
"port_arguments": {
"sc_uint": [
"11"
],
"sreg": [
"1",
"sc_uint"
]
},
"port_name": "u_reg_ex"
}Ports
{
"clk": {
"port_arguments": {
"sc_in": [
"_Bool"
]
},
"port_name": "clk"
},
"number_of_in_ports": 2,
"reset": {
"port_arguments": {
"sc_in": [
"_Bool"
]
},
"port_name": "reset"
}
}
{
"number_of_output_ports": 0
}
{
"number_of_inout_ports": 0
}
{
"number_of_instream_ports": 0
}
{
"number_of_outstream_ports": 0
}{
"number_of_other_vars": 1,
"u_reg_ex": {
"port_arguments": {
"sc_uint": [
"11"
],
"sreg": [
"1",
"sc_uint"
]
},
"port_name": "u_reg_ex"
}
}

Signal Declaration:

Signals
{
"c_sync": {
"signal_arguments": [
"_Bool"
],
"signal_name": "c_sync",
"signal_type": "sc_signal"
},
"count": {
"signal_arguments": [
"sc_uint",
"4"
],
"signal_name": "count",
"signal_type": "sc_signal"
},
"emax": {
"signal_arguments": [
"sc_uint",
"11"
],
"signal_name": "emax",
"signal_type": "sc_signal"
},
"emax_v": {
"signal_arguments": [
"_Bool"
],
"signal_name": "emax_v",
"signal_type": "sc_signal"
},
"number_of_signals": 4
}

Description

There is a difference in VarDecl and FieldDecl being declared in a module. The example below shows the difference. Currently, only FieldDecl are parsed.

Example

SC_MODULE(FIR) { 
// ...
int x;  // FieldDecl
const int ORDER = 5; // VarDecl
// ...
};

Description

Currently, the python tests using the pytest are named python-tests.
It is confusing and should be more precise.

Description

• sc_clk_in doesn’t get resolved to sc_in<_Bool>. The parsing in FindTemplateTypes does not go through to the primitive type in this case.

Using the version of the zfp test.cpp that instantiates find_emax, it appears that some of the port declarations aren't being generated. In particular, given the input code fragment below, the three declarations s_fp, m_fp, and m_ex, of type sc_stream_in, sc_stream_out, sc_stream_out respectively, are not being found in the port lists.

Input System C code fragment:

SC_MODULE(find_emax)
{
typedef typename FP::expo_t expo_t;

    /*-------- ports --------*/
    sc_in<bool> clk;
    sc_in<bool> reset;

    sc_stream_in <FP> s_fp;
    sc_stream_out<FP> m_fp;
    sc_stream_out<expo_t> m_ex;

    /*-------- registers --------*/
    sc_signal<sc_uint<2*DIM> > count;
    sc_signal<expo_t> emax;
    sc_signal<bool> emax_v;

Output _hdl.txt fragment below. Note that there are 2 port ins, no port outs, and then some var and signal declarations. but s_fp, m_fp, and m_ex are missing.

hModule find_emax_0 [
hPortsigvarlist NONAME [
hPortin clk NOLIST
hTypeinfo NONAME [
hType _Bool NOLIST
]
hPortin reset NOLIST
hTypeinfo NONAME [
hType _Bool NOLIST
]
hVardecl c_fp NOLIST
hTypeinfo NONAME [
hType struct fp_t<11, 52> NOLIST
]
hVardecl c_ex NOLIST
hTypeinfo NONAME [
hType find_emax<struct fp_t<11, 52>, 2>::expo_t NOLIST
]
hVardecl u_que_fp NOLIST
hTypeinfo NONAME [
hType struct fp_t<11, 52> NOLIST
]
hVardecl u_reg_ex NOLIST
hTypeinfo NONAME [
hType find_emax<struct fp_t<11, 52>, 2>::expo_t NOLIST
]
hSigdecl c_sync NOLIST
hTypeinfo NONAME [
hType _Bool NOLIST
]
hSigdecl count NOLIST
hTypeinfo NONAME [
hType sc_uint<2 * 2> NOLIST
]
hSigdecl emax NOLIST
hTypeinfo NONAME [
hType find_emax<struct fp_t<11, 52>, 2>::expo_t NOLIST
]
hSigdecl emax_v NOLIST
hTypeinfo NONAME [
hType _Bool NOLIST
]
]

The relevant code in the xlat plugin is below. It is called for each instance in the module instance map, and for each instance, calls the port processing code for IPorts, OPorts, IOPorts, OtherVars() and Signals. In the debug printout, "object name" appears for all the declarations except those 3.
test_hdl.txt

void Xlat::xlatport(ModuleDecl::portMapType pmap, hNode::hdlopsEnum h_op,
hNodep &h_info) {
static const std::setstd::string sctypes = {"sc_in", "sc_out", "sc_inout"};
for (ModuleDecl::portMapType::iterator mit = pmap.begin(); mit != pmap.end();
mit++) {
h_info->child_list.push_back(new hNode(get<0>(*mit), h_op));
os_ << "object name is " << get<0>(*mit) << "\n";
PortDecl *pd = get<1>(*mit);
hNodep h_typeinfo = new hNode(hNode::hdlopsEnum::hTypeinfo);
xlattype(pd->getTemplateType(), h_typeinfo); // sctypes, xlatout);//, os_);
h_info->child_list.push_back(h_typeinfo);
}
}

Description

The command for running python tests: ctest -R ... is cut-off when displayed and it can be confusing.

Hello,

I am new to systemc-clang, and I am interested in trying to use systemc-clang to transform code. I tried to follow the instructions inside doc/plugins.md to write a plugin for systemc-clang. I took the example program that was listed in the first half of the document and saved it as "ModelDump.h" under src/. Then I combined the existing driver-tooling.cpp file with what was listed in the second half of instructions so that my final driver-tooling.cpp file looked like this:

#include "SystemCClang.h"
#include "PluginAction.h"
using namespace scpar;
using namespace std;

// Include your class
#include "ModelDump.h"

int main(int argc, const char **argv) {
PluginAction systemc_clang(argc, argv);
PluginAction pa(argc, argv);
return 0;
}

Then I compiled systemc-clang normally. After I ran make, after several warnings, there were 2 errors shown below (only the output starting from the 1st error is shown):

In file included from /data/loewenheim/a/gpajela/Downloads/systemc-clang/driver-tooling.cpp:7:
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/ModelDump.h:11:6: error:
no matching constructor for initialization of 'scpar::SystemCConsumer'
: SystemCConsumer(ci) {
^ ~~
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/SystemCClang.h:61:9: note:
candidate constructor (the implicit copy constructor) not viable: no known
conversion from 'clang::CompilerInstance' to
'const scpar::SystemCConsumer' for 1st argument
class SystemCConsumer : public ASTConsumer,
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/SystemCClang.h:69:7: note:
candidate constructor not viable: requires 2 arguments, but 1 was provided
SystemCConsumer( CompilerInstance &, std::string top );
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/SystemCClang.h:110:59: error:
no matching constructor for initialization of 'ModelDump'
return std::unique_ptrclang::ASTConsumer( new A(ci, top_) );
^ ~~~~~~~~
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/SystemCClang.h:103:9: note:
in instantiation of member function
'scpar::LightsCameraAction::CreateASTConsumer' requested here
LightsCameraAction( std::string topModule ):top_{topModule} { };
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/PluginAction.h:33:18: note:
in instantiation of member function
'scpar::LightsCameraAction::LightsCameraAction' requested here
return new PluginConsumer(top_); }
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/PluginAction.h:31:14: note:
in instantiation of member function
'SimpleFrontendActionFactory<scpar::LightsCameraAction
>::create' requested here
explicit SimpleFrontendActionFactory( std::string topModule ): top_{...
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/PluginAction.h:53:26: note:
in instantiation of member function
'SimpleFrontendActionFactory<scpar::LightsCameraAction
>::SimpleFrontendActionFactory' requested here
factory.reset( new SimpleFrontendActionFactory< LightsCameraAction...
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/driver-tooling.cpp:11:27: note:
in instantiation of member function
'PluginAction::PluginAction' requested here
PluginAction pa(argc, argv);
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/ModelDump.h:10:2: note:
candidate constructor not viable: requires single argument 'ci', but 2
arguments were provided
ModelDump( CompilerInstance& ci)
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/ModelDump.h:6:7: note:
candidate constructor (the implicit copy constructor) not viable: requires
1 argument, but 2 were provided
class ModelDump
^
/data/loewenheim/a/gpajela/Downloads/systemc-clang/src/ModelDump.h:6:7: note:
candidate constructor (the implicit move constructor) not viable: requires
1 argument, but 2 were provided
14 warnings and 2 errors generated.
CMakeFiles/systemc-clang.dir/build.make:62: recipe for target 'CMakeFiles/systemc-clang.dir/driver-tooling.cpp.o' failed
make[2]: *** [CMakeFiles/systemc-clang.dir/driver-tooling.cpp.o] Error 1
CMakeFiles/Makefile2:68: recipe for target 'CMakeFiles/systemc-clang.dir/all' failed
make[1]: *** [CMakeFiles/systemc-clang.dir/all] Error 2
Makefile:94: recipe for target 'all' failed
make: *** [all] Error 2

Here are the versions of my software:

• systemc-clang: commit c8ee835
• CXX compiler: clang version 7.0.0-3~ubuntu0.18.04.1
• SystemC: 2.3.3
• OS: Ubuntu 18.04.3 LTS
• Platform: Linux x86_64

Given a for loop body.

We should separate out all the LHS and RHS variables of an assignment operation.
In case of other binary operation, both LHS and RHS are only read variables.

The template tree for top level ports, signals and variables is extremely useful to pass the type information out to the hnode parser. However, this information isn't available for fields within a structured type.
For example for a declaration sc_rvd_out<fp_t<11,52>> m_port, the template types are generated as
(sc_rvd_out) sc_rvd_out (sc_rvd_out) fp_t (fp_t) 11 (fp_t) 52 > Template args (DFT): sc_rvd_out fp_t 11 52
But for the fields within sc_rvd_out, such as ready, valid, data, there isn't a template arg tree. This means that the plugin will have to call the appropriate matcher to generate these trees or else write equivalent code to parse the field types.

Now, there are additional errors being generated from the catch header when compiling on a mac with clang 11.0.0. The prior one was "raise" on line 10630 being undeclared. The new errors after the last push are line 10639 signalstack being undeclared, 10645, 10657, 10660 sigaction having the wrong number of arguments (3, when 1 is required).

The build is failing due to the addition of the git submodules.

Latest CMakelists.txt uses LLVM_INSTALL_DIR rather than LLVM_BUILD_DIR but paths.sh and paths.fish in scripts have not been updated to set LLVM_INSTALL_DIR.

Description

When the top module is defined, the matchers only focus on the specified top-level module. Instead, any sub-modules that are declared within this top module should also be represented in the instance map.

The 'FindSignals' class does not recognize 'sc_signal' declarations when the provided type is a user-defined type via a typedef.

Description

After the introduction of the Tree class to represent the types, there is still some remnance of the old types. For example, getTemplateArgumentsType() should be marked as deprecated.

Related to issue #46.

Description

The module instance hierarchy should be represented in ModuleDecl. Currently, there is no clear way to access the module instance hierarchy.

The approach for this would be to find the Parent within which the instances are created. This Parent has a corresponding ModuleDecl. Within that ModuleDecl, one could have a vector of sub-modules represented as their respective ModuleDecls.

Description

The role of PortDecl is the same as SignalContainer. SignalContainer could simply be replaced.

This will also fix some of the memory free issues noted in ModuleDecl.cpp in function addPorts where the translation from PortDecl is done to SignalContainer.

Related to #88

Description

The script for running the Verilog conversion and the convert.py is fixed and is the tests/verilog-conversion/run-compare.py.

However, convert.py requires changes to correctly convert _hdl.txt into Verilog.

Description

Use include-what-you-use into the project to determine which include files must be included and others can use forward declarations. This is an enhancement to try and improve the compile times.

systemc-clang gives segmentation violation in scpar::FindTemplateTypes::VisitType (FindTemplateTypes.cpp:98) on test program examples/filter/main_sc.cpp when called from the xlat plugin file XlatEntryMethod.cpp:159 which is enumerating a template type retrieved from a VarDecl's getType() method.

Stack trace:

ProcessVarDecl type name is sc_bv<8>

Program received signal SIGSEGV, Segmentation fault.
0x00000000014148e6 in (anonymous namespace)::TypePrinter::printBefore(clang::QualType, llvm::raw_ostream&) ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.el7.x86_64 libgcc-4.8.5-39.el7.x86_64 libstdc++-4.8.5-39.el7.x86_64 ncurses-libs-5.9-14.20130511.el7_4.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) where
#0 0x00000000014148e6 in (anonymous namespace)::TypePrinter::printBefore(clang::QualType, llvm::raw_ostream&) ()
#1 0x00000000014138b1 in (anonymous namespace)::TypePrinter::printBefore(clang::Type const*, clang::Qualifiers, llvm::raw_ostream&) ()
#2 0x0000000001414aa5 in clang::QualType::getAsStringInternal(clang::Type const*, clang::Qualifiers, std::string&, clang::PrintingPolicy const&) ()
#3 0x0000000001414cbf in clang::QualType::getAsString(clang::Type const*, clang::Qualifiers, clang::PrintingPolicy const&) ()
#4 0x0000000001414db4 in clang::QualType::getAsString() const ()
#5 0x0000000000691b64 in scpar::FindTemplateTypes::VisitType (this=0x3b379a0,
type=0x3e12800)
at /home/gokhale2/sumac-home/src/systemc-clang-top/systemc-clang/src/FindTemplateTypes.cpp:98
#6 0x000000000069cda5 in WalkUpFromType (T=0x3e12800, this=)
at /home/gokhale2/local/llvm7/include/clang/AST/RecursiveASTVisitor.h:437
#7 WalkUpFromTemplateSpecializationType (T=0x3e12800, this=)
at /home/gokhale2/local/llvm7/include/clang/AST/TypeNodes.def:100
#8 TraverseTemplateSpecializationType (T=0x3e12800, this=0x3b379a0)
at /home/gokhale2/local/llvm7/include/clang/AST/RecursiveASTVisitor.h:1062
#9 clang::RecursiveASTVisitorscpar::FindTemplateTypes::TraverseType (
this=this@entry=0x3b379a0, T=..., T@entry=...)
at /home/gokhale2/local/llvm7/include/clang/AST/TypeNodes.def:100
#10 0x000000000069d170 in scpar::FindTemplateTypes::Enumerate (
---Type to continue, or q to quit---
this=this@entry=0x3b379a0, type=type@entry=0x3e12800)
at /home/gokhale2/sumac-home/src/systemc-clang-top/systemc-clang/src/FindTemplateTypes.cpp:70
#11 0x00000000007c715a in XlatMethod::ProcessVarDecl (
this=this@entry=0x7fffffffc1b0, vardecl=vardecl@entry=0x3e128a8,
h_vardecl=@0x7fffffffbee0: 0x448f980)
at /home/gokhale2/sumac-home/src/systemc-clang-top/systemc-clang/plugins/xlat/XlatEntryMethod.cpp:159
#12 0x00000000007c74d2 in XlatMethod::TraverseDeclStmt (
this=this@entry=0x7fffffffc1b0, declstmt=declstmt@entry=0x3e12d18)
at /home/gokhale2/sumac-home/src/systemc-clang-top/systemc-clang/plugins/xlat/XlatEntryMethod.cpp:144
#13 0x00000000007b7a13 in XlatMethod::TraverseStmt (
this=this@entry=0x7fffffffc1b0, stmt=0x3e12d18)
at /home/gokhale2/sumac-home/src/systemc-clang-top/systemc-clang/plugins/xlat/XlatEntryMethod.cpp:55
#14 0x00000000007c6f41 in XlatMethod::TraverseCompoundStmt (
this=this@entry=0x7fffffffc1b0, cstmt=cstmt@entry=0x3e1a6a0)
at /home/gokhale2/sumac-home/src/systemc-clang-top/systemc-clang/plugins/xlat/XlatEntryMethod.cpp:123
#15 0x00000000007b79fb in XlatMethod::TraverseStmt (
this=this@entry=0x7fffffffc1b0, stmt=0x3e1a6a0)
at /home/gokhale2/sumac-home/src/systemc-clang-top/systemc-clang/plugins/xla---Type to continue, or q to quit---q

Ideally, Verilog conversion golden data and Verilog tests should be in the same folder and both should be in an external module.

This is a problem that I thought was previously fixed, but noticed it again on the current master branch. Using the test.cpp example from the sc_zfp version the causes find_emax to be instantiated, certain type parameters are being repeated. So for the signal "data" in stream.h
sc_signal data;

we see the following generated .txt fragment below. Additionally, the sc_stream_0 module is being emitted three times. I wonder if this could be because the matcher is matching multiple rules and adding the matched item to the list each time.

hModule sc_stream_0 [
hPortsigvarlist NONAME [
hSigdecl data NOLIST
hTypeinfo NONAME [
hType sc_signal NOLIST
hType fp_t<11, 52> NOLIST
hType fp_t<11, 52> NOLIST
]
hSigdecl ready NOLIST
hTypeinfo NONAME [
hType sc_signal NOLIST
hType _Bool NOLIST
]
hSigdecl valid NOLIST
hTypeinfo NONAME [
hType sc_signal NOLIST
hType _Bool NOLIST
]
]

@zhuanhao-wu The recently added test sreg-test is failing. The reason seems to be that the SystemC code itself has an issue.

input.cc:16:15: error: no member named 'mc' in 'test'
    SC_METHOD(mc);
    ~~~~~~~~~~^~~
/home/twiga/code/systemc-2.3.3/systemc//include/sysc/kernel/sc_module.h:458:29: note: expanded from macro 'SC_METHOD'
                            func )
                            ^~~~~~
/home/twiga/code/systemc-2.3.3/systemc//include/sysc/kernel/sc_module.h:420:45: note: expanded from macro 'declare_method_process'
                name,  false, SC_MAKE_FUNC_PTR( host_tag, func ), \
                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
/home/twiga/code/systemc-2.3.3/systemc//include/sysc/kernel/sc_process.h:151:60: note: expanded from macro 'SC_MAKE_FUNC_PTR'
        static_cast<sc_core::SC_ENTRY_FUNC>(&callback_tag::func)
                                             ~~~~~~~~~~~~~~^
input.cc:23:3: error: no template named 'sc_stream'
  sc_stream<int> in_s;
  ^

There seem to be two issues that result in this:

1. I believe this has to be with the SC_METHOD(mc) description should be SC_METHOD(mc_entry).
2. sc_stream is not recognized. This is because an #include "sc_stream.h" may be missing.

@zhuanhao-wu I have not pushed in these changes because these may affect the assertions. Could you please take a look?

Description

Support for LLNL types: sc_stream_in, sc_stream_out.

This requires adding considerable support in identifying templates that are defined types. This means that the type is dependent on the template parameter.

I am not a contributor on this project, so can't do commits. Here are some the updates that

• restore othervars being available from ModuleDecl. It used to be there and then disappeared.
• updates to the xlat plugin to process othervars
• updates to the xlat plugin to process sensitivity list.
  diffs.txt

The commits made over the weekend don't appear in the synth branch. It might need a rebase in the synth branch.

Description

The _hdl.txt generated by member-variable-sc-buffer.cpp in the tests directory causes a lark parser error

Reproducing the bug

sh .sh member-variable-sc-buffer.cpp
python ../plugins/xlat/convert.py member-variable-sc-buffer_hdl.txt

Versions

• systemc-clang: branch scratchllnl
• CXX compiler: [clang-7.0.0]
• CXX flags: [ llvm-config --cxxflags]
• SystemC: [ 2.3.3]
• Operating System: [macos]

Minimal Working Example (MWE)

run with the specified example file, which is in the repo and was not modified.

Steps to Reproduce Bug

running convert.py on that file will trigger the bug

Expected behaviour

Expected to see generate verilog

Actual behaviour

parse error

Screenshots

python ../plugins/xlat/convert.py member-variable-sc-buffer_hdl.txt
WARNING:root:Shift/reduce conflict for terminal LPAR: (resolving as shift)
WARNING:root: * Reduce:
WARNING:root: * Shift: {<hliteral : LPAR * HLITERAL ID RPAR>}
WARNING:root:Shift/reduce conflict for terminal LSQB: (resolving as shift)
WARNING:root: * Reduce:
WARNING:root: * Shift: {<htype : * LPAR HTYPE ID RPAR>, <hvardef : hvardecl LSQB * htype htype RSQB hvardefsuf>, <hvardef : hvardecl LSQB * htype RSQB hvardefsuf>, <hvardef : hvardecl LSQB * RSQB hvardefsuf>}
WARNING:root:Shift/reduce conflict for terminal LPAR: (resolving as shift)
WARNING:root: * Reduce:
WARNING:root: * Shift: {<hvardecl : LPAR * HVARDECL ID RPAR>}
Traceback (most recent call last):
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 62, in get_action
return states[state][token.type]
KeyError: 'RSQB'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "../plugins/xlat/convert.py", line 329, in
main()
File "../plugins/xlat/convert.py", line 320, in main
t = l.parse(file_content)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/lark.py", line 311, in parse
return self.parser.parse(text, start=start)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parser_frontends.py", line 89, in parse
return self._parse(token_stream, start, *[sps] if sps is not NotImplemented else [])
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parser_frontends.py", line 54, in _parse
return self.parser.parse(input, start, *args)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 36, in parse
return self.parser.parse(*args)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 86, in parse
action, arg = get_action(token)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 65, in get_action
raise UnexpectedToken(token, expected, state=state)
lark.exceptions.UnexpectedToken: Unexpected token Token(RSQB, ']') at line 7, column 7.
Expected one of:
* LPAR

In the master branch, the code to save off variables declared in a module has been removed. This results in an sc_buffer not being included in a module. In the example below, we lose sc_buffer i[ORDER]:

 SC_MODULE(FIR) {
        sc_in_clk clk;
        sc_in<double> sample;       
        sc_out<double> result;
        SC_CTOR(FIR) {      
                SC_METHOD(behavior);
                sensitive << clk.neg();
        }
private:
        static const int ORDER = 5;
        static const double c[ORDER+1];
        sc_buffer<double> i[ORDER];
        void behavior() {
                double sum = c[0] * sample.read();
                for (int j=1; j<=ORDER; ++j)
                        sum = sum + c[j] * i[j-1].read();
                result.write(sum);

                i[0].write(sample.read());
                for (int j=1; j<ORDER; ++j)
                        i[j].write(i[j-1].read());
        }
};

Currently systemc-clang requires there to be a 'main()' as its starting point for finding module instances. It is often the case that the top-level module declaration is the only one required. There should be a way to specify this. Within this top-level module, there can be instantiations of other modules.

It would be good to have a standard error/warning reporting mechanism for the plugin. Maybe there is already something in place and I haven't found it. I'm looking for the best way to report to the user that "break" statements aren't handled and will be ignored.

Description

Provide a way to specify extra include dirs

When I try to parse the following file which does not contain main function
my_dut.h.txt

I get

Could not find SCMainsystemc-clang: /home/hassan/systemc-clang/src/FindSCMain.cpp:39: clang::FunctionDecl* scpar::FindSCMain::getSCMainFunctionDecl(): Assertion `!(_scmainFunctionDecl == __null)' failed.
Aborted (core dumped)

Is it possible to parse a file without main?

Description

The sensitivity list parsing does not capture function calls on classes that inherit from the sc_signal interface. For example, m_port.ready_chg() in the zfp1 example.

Description

Parse array of ports appropriately, and build a netlist for it.
The example that should pass is the portarray-example.cpp

Description

Rework the way in which other_fields are recognized. The main idea is to simply match other fields to FieldDecl and VarDecl. Then, just check that it is none of the prior desired port types. If it is not, then it is an other field. Otherwise, it will be one of the desired port types.

For the following:
sensitive << clk1.neg();

The dump routine is printing the subtree below, which doesn't include the "neg" part of the expression. I think it is saving off the tree at a lower point that is below the root with the .neg.

MemberExpr 0x1071d9cb0 'sc_core::sc_in_clk':'class sc_core::sc_in<_Bool>' lvalue ->clk1 0x1071d7ec0
`-CXXThisExpr 0x1071d9c98 'struct test *' this
sensitivity item clk1

Description

The synthesis modules in the xlat plugin are not being run

Reproducing the bug

Versions

• systemc-clang: latest in synthesis branch
• CXX compiler: clang 11.0.0
• CXX flags: [i.e. llvm-config --cxxflags]
• SystemC: 2.3.3
• Operating System: macos

Minimal Working Example (MWE)

When I use the run.sh script and run the filter example from the older systemc-clang revision, it doesn't go into the xlat module code. It does print XLAT plugin at the start, which verifies that it was compiled with the xlat plugin. When I did an nm of the systemc-clang executable, the methods in the xlat module don't appear. In my older version (sc-clang-xlat from my repo) there are lots of symbols related to xlat.

Also, I just redid the compilation, commenting out the automatic testing part since catch.hpp generates errors on the mac, and see that the files under plugins/xlat are not included in the compilation even though XLAT=on is printed out when it starts.

Description

For any type identified in a port of signal declaration, provide a way to access the respective type's field members.

Description

Instantiating a SystemC module (SC_METHOD) as a member variable of another module is not recognized as an instance. This occurs because of the way in which instances are discovered: there is no code that goes through the member variables of a module to identify instances.

Reproducing the bug

Run the attached MWE

Versions

• systemc-clang: 0.1
• CXX compiler: clang-7.0.0
• CXX flags: llvm-config --cxxflags
• SystemC: [2.3.3
• Operating System: Ubuntu 18.04

Minimal Working Example (MWE)

#include "systemc.h"
#include <iostream>

SC_MODULE( member_variable ) {
  void print() {
    std::cout << "This is an SC object as member variable" << std::endl;
  }
  void var() {
    std::cout << "I'm var?" << std::endl;
  }
  SC_CTOR( member_variable) {
  SC_METHOD(var);
  }
};

SC_MODULE( test ){
    sc_in<int> in;
    sc_out<int> out;
    sc_signal<int> test_signal;
    member_variable mv_in_test;

    void entry_function_1() {
      std::cout << "ef1: " << std::endl;
    }
    SC_CTOR( test ): mv_in_test("initialize_mv_in_test") {
        SC_METHOD(entry_function_1);
    }
};

int sc_main(int argc, char *argv[]) {
    sc_signal<int> sig1;
    test test_instance("testing");
    test_instance.in(sig1);
    test_instance.out(sig1);

    sc_start(100, SC_NS);
    return 0;
}

Steps to Reproduce Bug

1. Do this
2. Do that
3. Compile that

Expected behaviour

# SystemC model

# Number of modules : 3
# Module member_variable: 1 instances.
# Module sc_event_queue: 0 instances.
# Module test: 1 instances.

Actual behaviour

# SystemC model

# Number of modules : 3
# Module member_variable: 0 instances.
# Module sc_event_queue: 0 instances.
# Module test: 1 instances.

Notice that the member_variable instances is 0.

In the following tree, the FindTemplateTypes *te->enumerate() call is not enumerating the type arguments. First the source code, then the tree. In XlatEntryMethod.cpp where the enumerate call is occuring, there are no arguments, which generates a variable declaraion of notype.

(in zfp.h, line 231)
expo_t emax = s_ex.data_r();

Tree reported by the dump routine:
ProcessVarDecl var name is emax
ProcessVarDecl type name is fwd_cast<struct fp_t<11, 52>, 2>::expo_t
TypedefType 0x5748e20 'fwd_cast<struct fp_t<11, 52>, 2>::expo_t' sugar
|-Typedef 0x5748c68 'expo_t'
-ElaboratedType 0x5748c10 'typename struct fp_t<11, 52>::expo_t' sugar -TypedefType 0x562a820 'fp_t<11, 52>::expo_t' sugar
|-Typedef 0x5619348 'expo_t'
-TemplateSpecializationType 0x56192d0 'sc_uint<11>' sugar sc_uint |-TemplateArgument expr | -SubstNonTypeTemplateParmExpr 0x5619198 'int'
| -IntegerLiteral 0x5619178 'int' 11 -RecordType 0x56192b0 'class sc_dt::sc_uint<11>'
`-ClassTemplateSpecialization 0x56191c0 'sc_uint'

Description

When matching the templated modules, such as the sreg module in the example, it might create multiple module declarations for multiple instantiations with different type parameters.

Reproducing the bug

Running the sreg-test should reveal the problem.

Expected Behavior

The number of instances/declarations should match the number of instantiations in the code.

Actual Behavior

If we look at the number of instances/declarations generated for the three instances with different type parameters, we can observe there are 9 in total.

In the latest master branch, the systemc construct reset_signal_is is not being matched. Earlier today before I pulled the latest version of master, it appeared as a sensitivity list variable.

Description

TravisCI currently builds systemc-2.3.3 from source. Faster approach would be to use a pre-built binary. This will allow time to run ctest to run the tests as a part of the build.

Description

In order to run systemc-clang outside of the LLVM install folder, the appropriate include path must be added.

Something like:

-I$LLVM_INSTALL_DIR/lib/clang/9.0.0/include/

Description

The destruction of objects with Matchers and SystemCClang should be revisited. It seems that the destruction of dynamically objects are not done properly.

A general way to identify member instances of type sc_buffer requires a change to FindSignals.cpp such that the check is to see if there is a member variable whose declaration has a base class of sc_signal.

Using the latest master branch, I manually ran convert.py on sreg_hdl.txt (in examples/llnl-examples). It fails in the parsing phase with unexpected token at line 20 of sreg_hdl.txt.
Probably not worth fixing since we're waiting on the new convert.py, but just FYI.

python ../../plugins/xlat/convert.py sreg_hdl.txt
WARNING:root:Shift/reduce conflict for terminal HVARDECL: (resolving as shift)
WARNING:root: * Reduce:
WARNING:root: * Shift: {<hvardecl : HVARDECL * ID NOLIST>}
WARNING:root:Shift/reduce conflict for terminal HLITERAL: (resolving as shift)
WARNING:root: * Reduce:
WARNING:root: * Shift: {<hliteral : HLITERAL * ID NOLIST>}
Traceback (most recent call last):
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 62, in get_action
return states[state][token.type]
KeyError: 'HNOOP'
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "../../plugins/xlat/convert.py", line 535, in
main()
File "../../plugins/xlat/convert.py", line 526, in main
t = l.parse(file_content)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/lark.py", line 311, in parse
return self.parser.parse(text, start=start)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parser_frontends.py", line 89, in parse
return self._parse(token_stream, start, *[sps] if sps is not NotImplemented else [])
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parser_frontends.py", line 54, in _parse
return self.parser.parse(input, start, *args)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 36, in parse
return self.parser.parse(*args)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 86, in parse
action, arg = get_action(token)
File "/Users/gokhale2/anaconda3/lib/python3.7/site-packages/lark/parsers/lalr_parser.py", line 65, in get_action
raise UnexpectedToken(token, expected, state=state)
lark.exceptions.UnexpectedToken: Unexpected token Token(HNOOP, 'hNoop') at line 20, column 13.
Expected one of:
* HVARREF