• Content count

  • Joined

  • Last visited

About AmeyaVS

  • Rank
  • Birthday 02/28/1989

Profile Information

  • Gender
    Not Telling
  • Location

Contact Methods

  • Skype

Recent Profile Visitors

202 profile views
  1. Hello Andrei, From the provided logs I see you have a lot of clang and llvm defined in the path: PATH: /cygdrive/d/_Install/LLVM/bin PATH: /cygdrive/d/Install/CMake/bin PATH: /cygdrive/d/Install/gnuplot/bin PATH: /cygdrive/d/_Install/LLVM012017/LLVM/bin PATH: /cygdrive/c/_Program Files/LLVM/bin PATH: /cygdrive/d/Install/GnuWin32/getGnuWin/GetGnuWin32/gnuwin32/bin PATH: /cygdrive/d/Install/winhex PATH: /cygdrive/d/_Install/MinGW64_2/mingw64/bin PATH: /cygdrive/d/_Install/MinGW64/mingw32/bin PATH: /cygdrive/d/_Install/Msys2/mingw64/bin PATH: /cygdrive/d/_Install/SCBuilder/mingw32/bin PATH: /cygdrive/d/_Install/MinGW/msys/1.0/bin PATH: /cygdrive/c/Windows PATH: /cygdrive/d/Install/Vim PATH: /cygdrive/c/Program Files (x86)/Synopsys/QUASAR3-1.1.1-beta1/libso-msvc-10.0 PATH: /cygdrive/d/Install/Make PATH: /cygdrive/d/Install/GnuWin32/bin PATH: /cygdrive/d/Install/Vim PATH: /cygdrive/d/Install/GNU PATH: /cygdrive/d/Install/LLVM_vs2013/LLVM/bin Try to remove some of them. But first see if you are able to build a simple C++ application using Cygwin clang++. I suspect the clang++ executable is picking up libraries incompatible for it to execute properly. Note: Try to keep all the PATH/other environment variable as clean as possible. I usually have a central location batch/shell scripts from where I will source the environment variables required for the development environment. Windows is much harder development environment to work with and too slow for my preference. Regards, Ameya Vikram Singh
  2. Hello Andrei, I actually checked my SystemC config.log and observe similar behavior from the configure script. For now try building the library and see if the build is progressing or not. In case you are getting similar issue, then if possible try to use a Linux VM in a VirtualBox. If you are not able to use a Linux VM then as a last resort you can try installing cygwin but the performance will not be as good. In the mean time I'll try to find a system where MSYS2 is installed with similar package layout as yours to debug the build issue. Regards, Ameya Vikram Singh
  3. Hello, Would it be possible for you to share the bare minimum code files for the project, which reproduces this behaviour?(e.g.: Github/Gist etc.) Regards, Ameya Vikram Singh
  4. Hi Andrei, It seems you are trying to give windows absolute path to the configure script. Try running like this: $ ../configure --prefix=/d/Install/Libraries/systemc-2.3.1_llvm/systemc-2.3.1a --enable-pthreads --enable-debug If you are using the msys inbuilt bash shell then above command might be valid. You can verify the path mapping in msys bash shell with something like this: $ mount See if you are getting something like this instead of "C:" look for any entry showing "D:" and refer the path mapping (here it is on "/c" for you it might be "/d"): C: on /c type ntfs (binary,noacl,posix=0,user,noumount,auto) Also from the provided logs I am seeing that the pthread library is not installed. Kindly refer the msys setup for installing pthread threading library. Note: Look into the config.log file I am seeing many dependent packages are not installed: autoconf, automake etc. Regards, Ameya Vikram Singh
  5. Hello, Can you post the result of your configure step? I am able to build and use SystemC library under cygwin clang 3.9.1 with following steps: $ export CC=clang $ export CXX=clang++ $ ../configure --prefix=$HOME/apps/systemc-2.3.1a-clang --enable-debug --enable-pthreads $ make -j4 $ make check $ make install You can try to remove the "CFLAGS, CXXFLAGS and LDFLAGS" from your configure script parameters. Regards, Ameya Vikram Singh
  6. Hello, Also hit a build issue when mixing different compiler standard compiler flags: The build error: SystemC review error: when building example using c++11 option and compiler supports: C++14 also. CMakeFiles/ In function `__static_initialization_and_destruction_0': /home/ameya/sysc2.3.2_rew/include/sysc/kernel/sc_ver.h:179: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)' Compiler used g++ 6.3 Using same compiler to build systemc-2.3.1a results in no issues, also when mixing C++ standard compiler flags to build SystemC models. While building the SystemC_2.3.2_draft one has to maintain the C++ standard compiler flags(-std=c++11 or -std=c++14), that is supported by the g++ compiler by default and any project using overridden standard compiler flags also needed to be updated to to default compiler standard flags. Here are the differences in the symbols generated by the same compiler over different versions of systemc: SystemC-2.3.1a: (Using g++ 6.3.0) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000002c b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002a b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config_seen SystemC-2.3.2-draft review:(Using g++ 6.3.0) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 0000000000000028 b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002c b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config_seen Can anyone comment why C++ standard specific API specs are required? For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system. Is the SystemC library will be following this trend to build different version supporting different compiler standard flags? Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models. Would like to hear community members thoughts on this? Best Regards, Ameya Vikram Singh
  7. @daveW you can tryout the SystemC 2.3.2 draft release which fixes most of the issues while building under C++11/C++14 compilers. Have a look here: Regards, Ameya Vikram Singh
  8. Hello Everyone, I tried building the SystemC-2.3.2 draft release. The first failure I hit was the built-in make check tests failing under newer build environment. This problem has already been discussed in the forum: One possible solution(which is a temporary fix) has been discussed: Better solution would be to rename the examples folders under(It would also require some changes in the autotools config files): <SystemC Source>/examples/sysc/2.1 and <SystemC Source>/examples/sysc/2.3 to <SystemC Source>/examples/sysc/SC2.1 and <SystemC Source>/examples/sysc/SC2.3 repectively. I will try to send a patch for fixing the build. P.S: On the side note: Would it be possible to have an official publicly hosted repository? (Something on the lines of Github/Bitbucket, where one can provide patches or fixes to the issues). Provide faster turn around time to fix issues than waiting for an official release or comments. Better than polluting the forums with build issues, partial workarounds and patches floating around. Also it would not lead to spamming of the list with people facing similar issues or bug reports. It would be better that people discuss technically on SystemC usage and other issues or possible help/suggestions on the forum. I would love to hear from senior members of the forum on the same. Best Regards, Ameya Vikram Singh
  9. Hi, Can you share the build command (i.e. g++ <options> <input file> -o <output file>) in Release build? If you are using CMake you can generate build commands by running. make VERBOSE=1 in case you are using the autotools you can give this command to show the build commands. make V=1 For other tools you will have to look into documentation for getting the g++ build commands. Kindly post the results here to analyze further. Also if possible kindly share minimal code which reproduces this behavior. Regards, Ameya Vikram Singh
  10. Hello Shashidhar, You can look at the heading "Interoperability and the Base Protocol" on the same page on the Doulos TLM Tutorial page: Hopefully it helps, let me know. Regards, Ameya Vikram Singh
  11. Hi, You can look into the previous discussion on the same. You can also refer the Doulos TLM tutorial here about the tlm_utils. Regards, Ameya Vikram Singh
  12. Hi, Yes the TLM phase has to be in specific order. You can look into the examples folder for the "$SYSTEMC_HOME" installation folder, specifically at_1_phase, at_2_phase and at_4_phase sub-folder. $SYSTEMC_HOME/examples/tlm/ You can also look into a good documentation available in the "$SYSTEMC_HOME" install folder under doc folder, specifically slides: 36, 37, 38 about 1-Phase, 2-Phase, and 4-Phase transactions: $SYSTEMC_HOME/docs/tlm/release/TLM_2_0_presentation.pdf Hope this helps. Regards, Ameya Vikram Singh
  13. Hello, In SystemC you can use SC_THREAD's to model delays by using wait statements but you will incur performance penalty. Instead you can use event's and event queues to model delays using in SystemC as mentioned here: You can replace the SC_THREAD example given in the above mentioned link with SC_METHOD removing the infinite while loop. Here's the modified example listed from the above mentioned link: template<typename T> class delay_transport : public sc_module { public: sc_in<T> in; sc_out<T> out; SC_HAS_PROCESS(delay_transport); delay_transport(sc_module_name name_, sc_time tdelay_) : sc_module(name_), tdelay(tdelay_), in("in"), out("out") { SC_METHOD(mi); sensitive << in.default_event(); SC_METHOD(mo); sensitive << eq; } sc_time tdelay; void mi() { val =; vq.push(val); eq.notify(tdelay); } void mo() { val = vq.front(); out.write(val); vq.pop(); } sc_event_queue eq; std::queue<T> vq; T val; }; Regards, Ameya Vikram Singh
  14. Can you please share some details about your build environment such as compiler version you are using, etc.? Also kindly share the compilation option used the command that you have shared is showing only the use of object files for input and final executable "a.x" to be compiled and linked. Currently I am able to build the using this command on my system: g++ -g -Wall -std=c++11 -I $SYSTEMC_HOME/include -L $SYSTEMC_HOME/lib-linux64 -o test.cpp -lsystemc where g++ -v: g++ 5.4.0 Regards, Ameya Vikram Singh
  15. Currently I am working on G++ 5.4.0 and have tried setting the -std=c++98 and -std=c++03 and have observed no observable changes in the build library. But changing from one system to other resulted in SystemC library failing to build in one of the environments. I would recommend building the SystemC library without the "-std=c++03" compiler flag as you might get into some issues later when mixing other C++ libraries together while building System models. The make check is currently failing due to usage of shell script variables starting with numbers in the SystemC library which has been fixed in newer releases of the bash shell. Regards, Ameya Vikram Singh