Jump to content

AmeyaVS

Members
  • Content Count

    152
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by AmeyaVS

  1. Hello @katang, I have just taken cursory look into it, I think you are confusing the sc_fifo implementation which is just a communication abstraction for use in SystemC. What I think you are looking at is a module based communication model. Have a look here for hierarchical channels: https://www.doulos.com/knowhow/systemc/tutorial/hierarchical_channels/ Let me know if this helps you. Regards, Ameya Vikram Singh
  2. Hello @katang, It would be better if you would provide more details on what you are trying to achieve some diagrams or sample code. Regards, Ameya Vikram Singh
  3. Hello @katang, I have read somewhere that the dont_initialize() will be acknowledged with the last registered process is the SystemC kernel.(I will try to update once I find the reference for it.) In the mean-time you can see these resources for various discussion about processes in SystemC kernel which might provide you with some information you are looking for: https://sclive.wordpress.com/2008/01/10/systemc-tutorial-threads-methods-and-sc_spawn/ or here for some discussion: Regards, Ameya Vikram Singh
  4. Hello Katang, This has been already discussed previously. Take a look here: -Ameya Vikram Singh
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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/systemc.run.dir/src/main.cpp.o: 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
  11. @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
  12. 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 review-systemc@lists.accellera.org 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
  13. 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
  14. Hello Shashidhar, You can look at the heading "Interoperability and the Base Protocol" on the same page on the Doulos TLM Tutorial page: https://www.doulos.com/knowhow/systemc/tlm2/tutorial__1/ Hopefully it helps, let me know. Regards, Ameya Vikram Singh
  15. Hi, You can look into the previous discussion on the same. http://forums.accellera.org/topic/1603-simple-sockets-and-tlm-sockets/ You can also refer the Doulos TLM tutorial here about the tlm_utils. Regards, Ameya Vikram Singh
  16. 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
  17. 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: http://workspace.accellera.org/Discussion_Forums/helpforum/archive/msg/msg?list_name=help_forum&monthdir=200803&msg=msg00061.html 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 = in.read(); 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
  18. 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.run test.cpp -lsystemc where g++ -v: g++ 5.4.0 Regards, Ameya Vikram Singh
  19. 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
  20. Are you using the same compiler with which you have built the SystemC library? If yes, then probably the compiler is currently non-functional or you'll need some dependency packages which is currently missing from your system. Can you do a search for the file on your system for the mentioned shared library: liblto_plugin.so, probably under the path: /usr/lib/gcc/ or something similar? Currently on my system I am able to build the example code without any issues. Regards, Ameya Vikram Singh
  21. Hello, Sorry for misunderstanding the problem. But your problem seems to be too similar to the topic discussed here. Specifically the comments: Regards, Ameya Vikram Singh
  22. It seems you are using the sc_vector<>.init method incorrectly. As per the source from sc_vector.h you are trying to pass _size as a function pointer (Creator function). Can you make modifications from: explicit my_chnl(sc_module_name nm, unsigned _size = 4) : sc_channel(nm), fifos("FIFO") to: explicit my_chnl(sc_module_name nm, unsigned _size = 4) : sc_channel(nm), fifos("FIFO", _size) Also sc_fifo is template class what type are you specializing it to? If you are creating to a vector of sc_fifo of int datatype your declaration should be: sc_vector<sc_fifo<unsigned int> > fifos; //vectors of fifos Regards, Ameya Vikram Singh
  23. It would be better that you go ahead with your assignments. Try some simple examples see if they are building and the simulation is progressing. In case you hit any other issue you can post the details here. Regards, Ameya Vikram Singh
  24. It seems the problem lies in the test.sh script which prematurely stops execution due to setting up of Shell Script variable names starting with numbers. @donpalavi can you try to make following changes to the following file in the systemc-2.3.1a source code: File: config/test.sh.in Change the following line (line: 49) from: TESTNAME=`dirname "${TEST}" | sed "s:[^A-Za-z0-9_\@]:_:g" ` to: TESTNAME=`dirname "${TEST}" | sed "s:[^A-Za-z_\@]:_:g" ` This should temporarily resolves the SystemC unit test cases failures. As for the C++'03 you can try setting the CXX environment variable like this: export CXX="g++ -std=c++03" Regards, Ameya Vikram
  25. Strangely enough I am also facing make check issues under Cygwin (64-Bit) but earlier I didn't face any issues, will need to narrow down recent package updates. With g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.4.0 (GCC) @donpalavi you can download the systemc-regressions test suite from: http://accellera.org/downloads/standards/systemc or directly download from: http://accellera.org/images/downloads/standards/systemc/systemc-regressions-2.3.1a.tar.gz Then follow these steps to run the systemc-regressions test suite: export SYSTEMC_HOME="<path_to_your_SystemC_installation>" tar xf systemc-regressions-2.3.1a.tar.gz cd systemc-regressions-2.3.1a/ cd scripts/ # Run the verify.pl script with -arch configuration: # This command will run the entire test suite with SystemC and TLM test cases. # e.g.: ./verify.pl -arch linux64 systemc tlm # linux64: For 64-bit linux systems. # linux: For 32-bit linux systems. # cygwin: For 32-bit Cygwin Environment. # cygwin64: For 64-Bit Cygwin Environment. ./verify.pl -arch linux64 systemc tlm Wait for the test cases to build and verify the results(It will take some time as there are close to 858 test cases.) Currently in my environment 15 Test Cases under SystemC are failing and under TLM none of the test cases fail. Regards, Ameya Vikram Singh
×
×
  • Create New...