AmeyaVS

Hello @Gilbert Pajela, SystemC is C++, so it would be better to utilize C++ Tooling support to parse SystemC. And since @Roman Popov already mentioned Clang and LLVM tooling infrastructure you would have to fiddle with it to get necessary results. After Googling a bit found a reference to this paper: https://ieeexplore.ieee.org/document/6646649, and this project on GitHub: https://github.com/anikau31/systemc-clang Which have been updated quite recently. Hope it helps. Regards, Ameya Vikram Singh

Hello @SteveF, The enum tracing support is deprecated. You can find relevant discussions here: https://forums.accellera.org/topic/1309-enumeration-tracing/ https://stackoverflow.com/questions/53859127/how-to-trace-enum-type-in-a-vcd-file-using-systemc-ams There was another discussion about creating a mapping file between values and strings for usage in GtkWave for viewing VCD traces but currently unable to locate it. Will probably update the response or someone else can post the link to relevant discussion. Hope this small insight helps. Regards, Ameya Vikram Singh

Hello @rana, Here (http://karibe.co.ke/2014/02/setting-up-systemc-and-eclipse-for-c-hardware-simulation/) is a very detailed resource for setting up the Eclipse CDT IDE for SystemC related development. Though it is mentioned using Linux but you can find the steps 6 through 10 necessary for setting the project configurations which are anyway platform agnostic. Hope it helps. Regards, Ameya Vikram Singh

Hello @shubham_v, This new post does not contribute anything new or relevant to the previous discussion. As already the answers and resources provided by @David Black and @Eyck, have sufficient details. It looks as if you want to get your homework done by forum members. Can you at least put an effort to showcase what you have implemented till now? and also where you are stuck so that forum members can help you out with some more suggestions. Regards, Ameya Vikram Singh

Hello @aarone, Can you provide the initial logs from the SystemC kernel about the VCD timescale setting. Probably you are using the default VCD timescale, also the Warning itself is providing an insight that you need to revise the VCD timescale resolution. Hope it helps. Regards, Ameya Vikram Singh

Hello @charan, This is quite bold to copy the dll's into the systems core directory. It is usually a bad practice. Can you provide your build environment setup details(compilers, etc.)? Regards, Ameya Vikram Singh

Hello @shoji, Can you share a small example?, where it can be reproduced easily. That would help in narrowing down the issue. Regards, Ameya Vikram Singh

Hello @Jenkki_Menthol, The provided pseudo code and the description is not clear enough to provide any useful suggestions. Can you elaborate more on the exact problem statement probably with some very generic code to help you with some suggestions further? Regards, Ameya Vikram Singh

Hello @chatbq, There is not enough context, probably the exception is being thrown from another module. Overall the code seems fine. You can try and see from where the exception is being thrown from the debugger. Regards, Ameya Vikram Singh

Hello @egroj97, This is a known issue on Cygwin(64-bit) with QuickThreads. You need to pass the command-line option: "--enable-pthreads" to the configure script. Kindly refer the discussion about this here: On another note running applications built from source on Cygwin(64-bit) it much slower than running then on native Linux even within a VM. If you have Windows 10 with WSL(Windows Subsystem for Linux) then you could probably try that route to build and install the SystemC library. But I have not tried that out myself, and currently I do not see it being supported/validated by the working group. Anyway it will be nice to know if the library is functional on top of WSL. Hope this helps. Regards, Ameya Vikram Singh

Hello @katang, Here is a snippet from the SystemC release 2.3.3 file:(cmake/INSTALL_USING_CMAKE) containing reference to CMAKE_INSTALL_PREFIX CMAKE_INSTALL_PREFIX Root directory of the SystemC libraries installation (defaults to $ENV{SYSTEMC_HOME} if set to an absolute path and otherwise to either /opt/systemc/ (Unix-like platforms including CYGWIN), $ENV{ProgramFiles}/SystemC/ (on Windows systems), or ${CMAKE_INSTALL_PREFIX}/systemc. Anyway manually installing third party or other libraries in system path(like /usr or other path) is not advisable. I usually setup libraries/tools in my own user directories so as not to disturb other people working on the shared servers. Also I prefer to have a clean build workspace every time, i.e. I do not keep/reuse older build directories for my projects. Hope this helps. Regards, Ameya Vikram Singh

Hello @katang, As per your comments: CMAKE_INSTALL_PREFIX is never left uninitialized, here is the official CMake documentation: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT.html Anyway it is a very bad idea to install in the systems default location: /usr/local or something similar. In-case you have multiple SystemC installations and if you are using the CMAKE_MODULE_PATH or CMAKE_PREFIX_PATH variable, then you would probably need to see in what order are the paths specified. Hope it helps. Regards, Ameya Vikram Singh

Hello @katang, I am not an expert on this topic. But here is an article which summarizes the C++ Standard Changes after(C++98/03): https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/ One thing to understand is the standards body and the compiler teams came with solution to handle such underlying core changes, without the end user needing to completely rewriting their application and library implementations. With just a recompilation with newer standard flags gave most of the applications/libraries to start using the latest C++ standards features. Having a consistent compiler standards and other flags provides one with confidence that the application/library that one is shipping is meeting their expectations. And trust me you don't want to debug issues in library that got linked with slightly flags or slightly different API's and you are getting different run-time behavior of the application at every execution run(https://en.wikipedia.org/wiki/Heisenbug). Hope this helps. Regards, Ameya Vikram Singh

Hello @katang, It seems the issue is due to mismatch between the C++ compiler flags between your SystemC build and your application. Can you check if they are consistent? Regards, Ameya Vikram Singh

Hello @pmeyeratdatest, Can you specify the C++ Standard flag to the compilation command line parameters. # E.g.: g++ -std=c++11 <your_project_sources.cpp> -c <other_compiler_flags> Since It does not have any effect at link time. Thanks and Regards, Ameya Vikram Singh